The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / phrack1 / phrack23.005 < prev next >

Wrap

Text File | 2003-06-11 | 26.2 KB | 493 lines

==Phrack Inc.== Volume Two, Issue 23, File 5 of 12 <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> <> <> Foundations Upon The Horizon <> <> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <> <> Chapter Two of The Future Transcendent Saga <> <> <> <> Using Servers And Services In The World Of Bitnet <> <> <> <> Presented by Knight Lightning <> <> January 2, 1989 <> <> <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Welcome to the second chapter of The Future Transcendent Saga. In this file, I will present the servers and services of Bitnet (although there are some services and servers on other networks as well). You will learn what the servers are, how they differentiate, how to use them, and come to a better understanding of how these Foundations Upon The Horizon help make Bitnet a virtual Utopia. _______________________________________________________________________________ What Is A Server? ~~~~~~~~~~~~~~~~~ One of most useful features of Bitnet is the variety of file servers, name servers, relays, and so on. They might be described as "virtual machines" or "server machines." A "server" is a userid a lot like yours. It may exist on your computer (node) or on some other BITNET node. The people who set up this userid have it running a program that will respond to your commands. This is a "server." The commands you send and the way in which the server responds to them depends on the particular program being run. For example, the servers UMNEWS@MAINE and 107633@DOLUNI1 offer different types of services, and require different commands. The various kinds of servers are described later in this document. You can send your commands to most servers in one of two formats: MAIL or MESSAGE. Not all servers accept commands via both formats, but this information is included in the document BITNET SERVERS which can be obtained from LISTSERV@BITNIC. Because there are so many servers I will not even begin to list them here. Different servers are created and disconnected everyday so it would be difficult to name them all. People on VM/CMS systems would send commands something like this: TELL userid AT node command (AT = @) For example: TELL NETSERV@MARIST HELP People on VAX/VMS systems using the JNET networking software would use this syntax: SEND userid@node "command" For example: SEND NETSERV@MARIST "HELP" Many servers can also accept commands via mail. Indeed, some will only accept your commands in that format, such as the servers on the non-Bitnet nodes. The syntax for the commands you send remain the same. You send mail to the server as if you were sending the mail to a person. The text of your message would be the command. Some servers will take the command as the first line of a text message, others require it in the "Subject:" line. Some servers will accept more than one command in a mail message, others will take only one. Here is an example of a mail message sent to LISTSERV@BITNIC requesting a list of files: Date: Fri, 30 Dec 88 23:52:00 EDT From: Taran King <SYSOP@MSPVMA> To: Listserv <LISTSERV@BITNIC> ======================================================================== INDEX Throughout this file I will use examples where commands are sent to servers via message. However, for many of the cases we will present you have option of using mail. The choice is yours. There are two particularly confusing aspects of servers of which you should be aware. First, servers in the same category (say, file servers) do not always accept the same commands. Many of them are extremely different. Others are just different enough to be annoying. There are many approaches to setting up a server, and everyone is trying to build a better one. The second problem is that there are many servers that fill two, sometimes three categories of server. For example, LISTSERV works as a list server and a file server. Many LISTSERVs have been modified to act as name servers as well, but they are rather inefficient in this capacity. If you do not understand this terminology, bear with me. The best is yet to come. File Servers ~~~~~~~~~~~~ Remember that a server runs on a userid much like yours. Like your userid, it has many capabilities, including the ability to store files (probably with a much greater storage capacity though). The program that a file server runs enables it to send you files from its directory, as well as a list of files available. These may be programs or text files. You might look at these servers as Bitnet versions of dial-up bulletin boards or AE Lines. You can generally send three types of commands to a file server. The first type is a request for a list of files the server offers. The second is a request that a specific file be sent to your userid. The third, and most important is a HELP command. The HELP command is very important because it is one of the few commands that almost all servers accept, no matter what the type. Because the commands available differ from server to server, you will often find this indispensable. Sending HELP to a server will usually result in a message or file sent to your userid listing the various commands and their syntax. You should keep some of this information handy until you are comfortable with a particular server. To request a list of files from a server, you will usually send it a command like INDEX or DIR. The list of files will be sent to you via mail or in a file. For example: VM/CMS: TELL LISTSERV@BITNIC INDEX VMS/JNET: SEND LISTSERV@BITNIC "INDEX" To request a specific file from the list you receive, you would use a command like GET or SENDME. For example to request the file BITNET TOPOLOGY from LISTSERV@BITNIC you would type on of the following: VM/CMS: TELL LISTSERV@BITNIC SENDME BITNET TOPOLOGY VMS/JNET: SEND LISTSERV@BITNIC "SENDME BITNET TOPOLOGY" In many cases the files are organized into subdirectories or filelists. This can make requesting a file more complicated. This makes it even more essential that you keep documentation about a particular server handy. Some file servers offer programs that you can run which will send commands to the server for you. Name Servers ~~~~~~~~~~~~ Name servers serve two purposes; to assist you in finding an address for someone or to help you find people with specific interests. I doubt you are going to care about tracking down people by their interests, so I am not going to discuss those aspects of nameservers. The servers that actually let you look up people are few and far between. Because there are so few I have composed this list; Columbia University FINGER @ CUVMA Cork University INFO @ IRUCCIBM Drew University NAMESERV @ DREW North Dakota State University FINGER @ NDSUVM1 Ohio State University WHOIS @ OHSTVMA Pennsylvania State University IDSERVER @ PSUVM Rochester Institute Of Technology INFO @ RITVAXD LOOKUP @ RITVM State University of New York (SUNY) at Albany WHOIS @ ALBNYVM1 University of Calgary NAMESERV @ UNCAMULT University of Kentucky WHOIS @ UKCC University of Illinois at Urbana-Champagne PHSERVE @ UIUCVMD University of Louisville (Kentucky) WHOIS @ ULKYVM University of Regina VMNAMES @ UREGINA1 University of Tennessee UTSERVER @ UTKVM1 Weizmann Institute of Science VMNAMES @ WEIZMANN So as not to be misleading, these servers do not necessarily cover the entire school. Example: The server at University of Louisville covers people on the node ULKYVM, but not the nodes ULKYVX0x (x = 1 - 8 I believe). ULKYVX is a VAXcluster of nodes at University of Louisville, but the people on those systems are NOT indexed on the server at ULKYVM. In contrast, the nameserver at University of Illinois contains online listings for every student and staff member whether they have accounts on the computer or not. You can get phone numbers and addresses using this. Please note that the above list is only to the best of my knowledge and others may exist. There are also many Listservs that have a command to search for people, but with Listserv, signing up is by choice and not mandatory. You also will end up getting listings for people from nodes other than the one you are searching. Ok, lets say I am trying to find an account for Oryan QUEST and I am told by a friend that he is going to school at Ohio State University. Ohio State University has a nameserver and if he has an account on their computer I should be able to find him. VM/CMS: TELL WHOIS@OHSTVMA Quest VMS/JNET: SEND WHOIS@OHSTVMA "Quest" This particular nameserver only requires that you enter the persons name with no "search" command. Some servers require this. Your best bet is to send the command "HELP" first and you'll receive documentation. Ok, back to the example... unfortunately, there is no entry for "Quest" and I am out of luck. I should have been smart enough to realize that no college would be likely to let Oryan QUEST enroll in the first place -- my mistake. In any case, I highly recommend that you register yourself with UMNEWS@MAINE and BITSERVE@CUNYVM. These are popular nationwide servers that are often used to locate people. Forums, Digests, and Electronic Magazines ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The concept of mailing lists has been given new life with the creation of computer networks. Let me explain what I mean. Almost everyone is on some sort of mailing list; magazines, bills or even pamphlets from your congressman.. The computer networks have brought a whole new degree of speed and functionality to mailing lists, as you will see. In Bitnet, mailing lists are used mainly to keep people with similar interests in contact. There are several formats in which this contact can take place. These are "forums," "digests," and "electronic magazines". FORUMS are a good example of how the utility of mailing lists has been expanded in Bitnet. Let's say that you have subscribed to a forum for people interested in Cyberpunks. How you could subscribe to such a list will be described later. Another person on the mailing list sends mail to a server where the list is kept. This server forwards the mail to all of the people in the forum. When mail from a forum arrives in your computer mailbox, the header will look much like this: Date: Fri, 10 Sep 88 23:52:00 EDT Reply-To: CYBER Discussion List <CYBER-L@PUNKVM> Sender: CYBER Discussion List <CYBER-L@PUNKVM> From: Sir Francis Drake <DRAKE@WORMVM> Subject: Invasion From X-Neon! To: Solid State <SEKER@PLPVMA> ======================================================================== This may look a little confusing, but there really isn't much to it. In this example, Sir Francis Drake ("From:") sent mail to the CYBER-L list address. This server then forwarded the mail to everybody on the list, including Solid State ("To:"). Note the line named "Reply-To:". This line tells your mail software that when you reply to the note (if you reply) that the reply should go to the list... meaning *everybody* on the list. People will in turn reply to your mail, and you have a forum. Some forums are very interesting, but using the digests can lead to problems. First among these is the volume of mail you can receive. If you are in a very active forum, you can get 50 or more pieces of electronic mail in a single day. If you are discussing a controversial or emotional topic, expect more. Many people have a tendency to "flame" (the Bitnet term for ragging). The speed and immediacy of electronic mail makes it very easy to whip out a quick, emotional response, to which there will be similar replies. I advise you to take some time and think out your responses to forum postings before inadvertently starting a "flame war." Hopefully anyone able to gain access to college computers will be mature enough to have outgrown these battles. DIGESTS provide a partial solution to the these problems. In this case, mail that is sent to a mailing list is stored rather than sent out immediately. At some point the "Moderator" for the list organizes and condenses all of the correspondence for the day or week. He then sends this out to the people on the mailing list in one mailing. The drawback with this setup is that it requires a lot of human intervention. If the moderator gets sick, goes on vacation, or quits, activity for a particular digest can come to a screeching halt. ELECTRONIC MAGAZINES take the digest concept a step further. These mailing lists actually duplicate the organization and format of "real" magazines. Bitnet is used as a convenient and inexpensive distribution method for the information they contain. The frequency of distribution for these electronic magazines ranges ranges from weekly to quarterly to "whenever the editor feels like it" (sort of like Phrack releases). This is the most formal, structured form of Bitnet communication. Where a digest is simply a group of letters organized by topic, an electronic magazine includes articles, columns, and features. Perhaps the only feature of paper magazines that they do *not* include is advertisements. Bitnet NetMonth and NetWeek are two of the better magazines on Bitnet and they contain useful information if you know what you're looking for. I will discuss how to subscribe to these magazines as well as the other forms of media in the next part of this file. List Servers ~~~~~~~~~~~~ In the previous section, I mentioned that some servers are used to control mailing lists. A server that performs this function is called a "list server." Almost all of these listservers have the userid of LISTSERV, such as LISTSERV@BITNIC. One of these servers can control subscriptions to many mailing lists. The other concept behind Listservs are the list-ids, but as these are rather unimportant and vary from server to server I am not going to discuss them here. If you would like to learn about these, consult your local listserv and request documentation with the HELP command. To subscribe to a mailing list, you would send a LISTSERV a SUBSCRIBE command, which has the following syntax: SUBscribe listname (whatever name you want) In this example, SpyroGrya is sending LISTSERV@BITNIC the command to subscribe to ETHICS-L: VM/CMS: TELL LISTSERV@BITNIC SUB ETHICS-L SpyroGyra VMS/JNET: SEND LISTSERV@BITNIC "SUB ETHICS-L SpyroGyra" If you misspell your name when entering a SUBscribe command, simply resend it with the correct spelling. To delete his name from the mailing list, SpyroGyra would enter an UNSUBscribe command: VM/CMS: TELL LISTSERV@BITNIC UNSUB ETHICS-L VMS/JNET: SEND LISTSERV@BITNIC "UNSUB ETHICS-L" In many cases the SIGNOFF command is used instead of UNSUB, but those are the basic commands you need to know in order to access Listserv controlled mailing lists. However, Listserv has a multitude of features, so it would be a good idea to read the Listserv documentation. *Note* If you are on a VAXcluster, you should send SUBSCRIBE and UNSUBSCRIBE commands to LISTSERV via MAIL. Relays ~~~~~~ Relay might be one of the easier types of servers to understand. If you have used the CB Simulator on CompuServe or are familiar with Diversi-Dials (or maybe even ALTOS Chat) you will catch on to the concept quickly. The idea behind Relay is to allow more than two people to have conversations by interactive message. Without Relay-type servers, this would not be possible. Let's set up a scenario: Sluggo, Taran, and Mentor are at different nodes. Any two of them can have a conversation through Bitnet. If the three of them want to talk, however, they have a problem. Sluggo can send Mentor messages, but Taran can't see them. Likewise, Taran can send Sluggo messages, but then Mentor is in the dark. What they need is a form of teleconferencing. Alliance doesn't exist on Bitnet so they created Relays. Each of these users "signs on" to a nearby Relay. They can pick a channel (0-999 although there are more, but they are reserved for special use). Instead of sending messages to Taran or Sluggo, Mentor sends his commands to the Relay. The Relay system then sends his message to *both* Taran and Sluggo. The other users can do the same. When they are done talking, they "sign off." Relays can distinguish commands from the text of your messages because commands are prefixed with a slash "/". For example, a HELP command would look like this: VM/CMS: TELL RELAY@UIUCVMD /HELP VMS/JNET: SEND RELAY@UIUCVMD "/HELP" A message that is part of a conversation would be sent like so: VM/CMS: TELL RELAY@UIUCVMD Hello there! VMS/JNET: SEND RELAY@UIUCVMD "Hello there!" When you first start using Relay, you must register yourself as a Relay user using the /SIGNUP or /REGISTER commands: VM/CMS: TELL RELAY@UIUCVMD /REGISTER (Choose a name) VMS/JNET: SEND RELAY@UIUCVMD "/REGISTER (Choose a name)" They want you to use your real name, do so if you want, but they really have no way to check unless one of the operators is a user consultant at your node and looks up your account. Just use names that look real and you'll be fine. You can then sign on. You can use a nickname or handle. In the following example, I am signing on to Channel 260 with a nickname of "KLightning": VM/CMS: TELL RELAY@UIUCVMD /SIGNON KLightning 260 VMS/JNET: SEND RELAY@UIUCVMD "/SIGNON KLightning 260" You can then start sending the Relay the text of your messages: VM/CMS: TELL RELAY@UIUCVMD Good evening. VMS/JNET: SEND RELAY@UIUCVMD "Good evening." Relay messages will appear on your screen like this. Note the nickname near the beginning of the message. When you send conversational messages to the Relay, it automatically prefixes them with your nickname when it forwards it to the other users: FROM UIUCVMD(RELAY): <Taran_King> Hello KLightning. You can find out who is on your channel with a /WHO command. In the following example, someone is listing the users on Channel 260. VM/CMS: TELL RELAY@UIUCVMD /WHO 260 VMS/JNET: SEND RELAY@UIUCVMD "/WHO 260" The response from the Relay would look like this: FROM UIUCVMD(RELAY): Ch UserID @ Node Nickname FROM UIUCVMD(RELAY): 260 C483307@UMCVMB (KLightning) FROM UIUCVMD(RELAY): 260 MENTOR@PHOENIX (The_Mentor) FROM UIUCVMD(RELAY): 260 C488869@UMCVMB (Taran_King) FROM UIUCVMD(RELAY): 260 PROPHET@PHOENIX ( Prophet ) FROM UIUCVMD(RELAY): 260 DRAKE@WORMVM ( Sfd ) FROM UIUCVMD(RELAY): 260 JESTER@NDSUVM1 ( Sluggo ) FROM UIUCVMD(RELAY): 260 TUC@RACS3VM ( Tuc ) FROM UIUCVMD(RELAY): 260 VINNY@LODHVMA (Lex_Luthor) When you are done with your conversation, you can sign off the Relay: VM/CMS: TELL RELAY@UIUCVMD /SIGNOFF or /BYE VMS/JNET: SEND RELAY@UIUCVMD "/SIGNOFF" or "/BYE" There are several commands for listing active channels, sending private messages, and so on. When you first register as a Relay user, you will be sent documentation. You can also get this information with the /INFO command. To determine which Relay serves your area, send any of the Relays listed in BITNET SERVERS the /SERVERS command. Also, because of Bitnet message and file traffic limits, many Relays are only available during the evening and weekends. To help illustrate how the Relays work I have included this map; [United States of America locations only] ---------------------- Non-USA Relays | RELAY @ CLVM | ^ | (TwiliteZne) | /|\ | Potsdam N.Y. | | ---------------------- | | ---------------------- ---------------------- ---------------------- | RELAY @ VILLVM | | RELAY @ ORION | | RELAY @ YALEVM | | (Philadelph) |-----| (New_Jersey) |-----| (Yale) | | Villanova PA. | | New Jersey | | New Haven CT. | ---------------------- ----------------------\ ---------------------- | | \ ---------------------- | \ \ ---------------------- | RELAY @NDSUVM1 | | \ \ | RELAY @NYUCCVM | | (No_Dakota ) |\ | \ \| ( Nyu ) | | North Dakota | \ | \ | New York | ---------------------- \ | \ ---------------------- \ | \ ---------------------- \---------------------- | ---------------------- | RELAY @JPNSUT10 | | RELAY @ BITNIC | | | CXBOB @ASUACAD | | ( Tokyo ) |-----| ( NewYork ) | | | (Tempe_Ariz) | | Japan | | New York-Singapore | | | Arizona | ---------------------- ---------------------- | ---------------------- | | | ---------------------- \ | ---------------------- | MASRELAY@ UBVM | \ | | RELAY @ USCVM | | ( Buffalo ) |\ --+--| (LosAngeles) | | New York (N) | \ / | California | ---------------------- \ / ---------------------- \ / | ---------------------- \ / ---------------------- | RELAY @ WATDCS | \ / | RELAY @ UWAVM | | ( Waterloo ) | \ / | ( Seattle ) | | Ontario/E. Canada | | / | Washington | ---------------------- | / ---------------------- | | | | ---------------------- ---------------------- ---------------------- | RELAY @CANADA01 | | RLY @CORNELLC | | 556 @OREGON1 | | ( Canada01 ) |-----| (Ithaca_NY ) | | ( Oregon ) | | Ontario (Guelph) | | New York | | Oregon | ---------------------- ----------------------\ ---------------------- | | \ ---------------------- | \ ---------------------- | RELAY @UREGINA1 | | \ | RELAY @ VTVM2 | | ( Regina_Sk ) | | \| ( Va_Tech ) | | Saskatoon/Manitoba | | | Virginia | ---------------------- | ---------------------- | | | ---------------------- | ---------------------- | RELAY @UALTAVM | | | RELAY @ UWF | | ( Edmonton ) | | | (Pensacola ) | | Alberta/B.C. | | | Florida | ---------------------- | ---------------------- | ---------------------- ---------------------- ---------------------- | RELAY @PURCCVM | | RELAY @CMUCCVMA | | RELAY @ UTCVM | | ( Purdue ) |-----| (Pittsburgh) |-----| (Tennessee ) | | Lafayette IN. | | Pennsylvania | | Tennessee | ---------------------- ---------------------- ---------------------- | | ---------------------- | ---------------------- | RELAY @TECMTYVM | | | RELAY @ GITVM1 | | (Monterrey ) | | | ( Atlanta ) | | Mexico | | | Georgia | ---------------------- | ---------------------- | | ---------------------- ---------------------- ---------------------- | RELAY @ TAMVM1 | | RELAY @UIUCVMD | | RELAY @ TCSVM | | (Aggieland ) |-----| (Urbana_IL ) |-----| ( Tulane ) | | Texas | | Illinois | | New Orleans LA. | ---------------------- ---------------------- ---------------------- Conclusion ~~~~~~~~~~ So what lies beyond the boundaries of Bitnet? There are many other networks that are similar to Bitnet both in function and in services. How to mail to these networks will be discussed in the next chapter of The Future Transcendent Saga -- Limbo To Infinity. :Knight Lightning _______________________________________________________________________________