NetNews Usenet Archive 1993 #1

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

/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / os2 / networki / 2701 < prev next >

Wrap

Internet Message Format | 1993-01-12 | 29.9 KB

Path: sparky!uunet!spool.mu.edu!olivea!mintaka.lcs.mit.edu!ogicse!news.u.washington.edu!milton.u.washington.edu!fhl From: fhl@milton.u.washington.edu (Dean Pentcheff) Newsgroups: comp.os.os2.networking Subject: Getting started with OS/2 networking using IBM's TCP/IP software Message-ID: <1ivusiINNrpa@shelley.u.washington.edu> Date: 13 Jan 93 02:30:42 GMT Sender: Dean Pentcheff Reply-To: dean2@tbone.biol.scarolina.edu (Dean Pentcheff) Followup-To: comp.os.os2.networking Organization: Department of Biology, University of South Carolina, Columbia Lines: 678 NNTP-Posting-Host: milton.u.washington.edu ============================================================================= Document: ftp-os2.nmsu.edu:/pub/os2/2.0/network/tcpstart.txt Guide to getting started with OS/2 networking using IBM's TCP/IP software ============================================================================= Recent Changes Dec 16 1992 Numbered sections, added table of contents. Fixed up LAPS section to avoid premature quitting with "OK". Dec 15 1992 Added suggestion to run lpd in foreground with -b -c flags. Reminder to usually leave "network Adapter Address" blank. Minor rehash to avoid recommending doing a full-screen inetd. ============================================================================= Table of Contents (find sections by searching for the parenthesized number) (0) Purpose and introduction (1) Request for more information (2) Some terminology (3) Selecting parts of the IBM TCP/IP packages (4) Preparing to hook up to a TCP/IP network (5) Installing IBM's TCP/IP Package (6) Installing the driver for the network adapter (7) Initial tryout (8) Downloading CSDs (bug fixes) (9) A few reminders (10) Security concerns (11) Good luck ============================================================================= ---------------------------- (0) Purpose and introduction ---------------------------- The purpose of this document is to: 1) Orient someone who has heard a bit about networking on OS/2, but can't yet hold an entire conversation in three to five letter networking acronyms ("So, Bob, how's TCP/IP coming along today?" "Well, Jane, NFS if fine, but I'm having trouble with FTP." "Have you installed the CSDs?" "Yes, but can you ping over SLIP before sending a job to LPD?"....). 2) Help a new networker install the IBM TCP/IP networking package and some of its more popular additional modules. I'm no networking pro, but I've managed to start a working network system using OS/2 and IBM's TCP/IP offerings. It took me long enough to sort it all out. I hope I can save someone else the trouble. I make no guarantees that the following is entirely correct! It's based on my experiences. PLEASE correct me by mailing me your comments if you find anything misleading or wrong. Please send me additional hints based on your own experiences that you feel would be helpful to put into this document. -Dean [NOTE: my email address is different than the address from which I post news] Dean Pentcheff (Internet: dean2@tbone.biol.scarolina.edu) (803) 777-8998 Department of Biology, University of South Carolina, Columbia SC 29205 -------------------------------- (1) Request for more information -------------------------------- Please let me know of improvements I can make to this document! Notable gaping holes that I notice (hint, hint) are: 1) Tuning issues - how to improve performance, both of network transfers in general, and of the whole OS/2 system when networking is installed. For example, I notice my system thrashing more when the network software is installed. 2) SLIP configuration and debugging. I don't use SLIP, so I have no experience here. 3) Other useful network software - surely some net.geeks have some nifty utilities and addons that make a networked OS/2 system more of a joy. 4) Netware connectivity - I haven't done it, so I have no knowledge. -------------------- (2) Some terminology -------------------- TCP/IP is the name of a communications protocol - it defines a way for computers to chat with each other. PC/TCP is a particular product (?) that uses TCP/IP on a PC. It is not addressed in this document - you may have heard about it from DOS systems. The programs described here do what PC/TCP on DOS does (and more). Ethernet is a specific hardware protocol for computer communications. For example, a 3Com 3C503 card is a (very cheap and popular, if not screamingly fast) Ethernet board for PCs. Using it (and appropriate software) you can connect a PC to an Ethernet TCP/IP network. TCP/IP is just one of many communication protocols that can run atop Ethernet. For example, a Novell Netware network running the IPX protocol could run on the same Ethernet - same hardware, just different protocols. FTP is a "file transfer protocol" that runs on top of TCP/IP (there are implementations of FTP for pretty much any computer that can talk TCP/IP, making it a lingua franca for file exchange - it's not pretty but it works). Telnet is a defined way for TCP/IP-speaking computers to set up terminal sessions between each other so that you can actually log onto a remote computer and interact with your account there. SLIP stands for serial line IP. It defines a way that you can connect to a TCP/IP network over a serial line (via a phone modem, for example). Serial communications is slower than a direct network connection, but can sometimes be useful. IBM's TCP/IP packages does support SLIP. CSD is IBM's word for a publicly distributed bug fix package. Note that CSDs obsolete prior CSDs. That is, application of any later CSD will take care of everything that was done by earlier CSDs. You don't have to apply the whole chronological string of CSDs, just the most recent one. God help you if you install an earlier CSD over a later one (IBM sure won't help). -------------------------------------------- (3) Selecting parts of the IBM TCP/IP packages -------------------------------------------- IBM sells a bunch of pieces, many of which are optional, for TCP/IP networking. Following is a brief summary of them. Note that all of the following come with both 1.2 Mb 5-1/4" and 1.44 Mb 3-1/2" disks in the same package (you don't need to specify medium). TCP/IP Base Program (Part #02G6968). You need this in order to use any of the other following parts. It gives you the software to connect your Ethernet or Token Ring card to a network, plus a few character-oriented programs (Telnet, FTP, ping, etc.). It's sort of equivalent to the public domain NCSA Telnet package for DOS. NFS Kit (Part #02G6970). This gives your OS/2 system the ability to serve as both a client and a server for sharing disk space using Sun's NFS (Network File System) protocol. In other words, you can mount disks over the network that are physically attached to other minicomputers or OS/2 systems as though they were attached to your computer. Conversely, you can make parts of your OS/2 computer's disks available for sharing by others. With this package (along with the Base Program), you've got the makings of a small local area network that can share disk space and printers. X-Windows System (Part #02G6980). This gives your OS/2 system the ability to display output (and relay input) to X programs running on other computers. X-Windows is a standardized way for programs (mostly on Unix-based systems) to put graphics on the screen and interact with the user. X terminology is a bit peculiar: the program doing the work is called the "client"; the program doing the display is called the "server". This package allows your OS/2 system to be an "X server", but not an "X client": you can display and interact with X programs running elsewhere, but you can't run an X program on your OS/2 system and have its results displayed elsewhere. X.25 Networking (Part #?). Enables X.25 communications from your OS/2 system. I have no exposure to this product, so I won't comment. I assume you'll know if you need it. Source code and programming packages. If you're ordering these you sure as hell don't need me giving you hints on what to do. Oh yes, prices. The following prices are the US educational discount prices for the items about which I know. Commercial prices are about 35% higher. Order direct from IBM. TCP/IP Base Program $130.00 NFS $ 98.00 X-Window System $ 98.00 -------------------------------------------- (4) Preparing to hook up to a TCP/IP network -------------------------------------------- Once you have the TCP/IP base package, you can be a full-blown node on the Internet. To do that, you _must_ contact a local system adminstrator on the network to which you will physically connect your OS/2 machine. He or she must give you an Internet number. Choosing one at random is unlikely to work and is exceedingly antisocial (since it may well disrupt others' use of the network). You can probably select your own cute name for your machine, unless there is an iron-fisted net administrator who enforces a naming convention. As examples, our lab works on crab behavior, so our PCs are called "fiddler" and "cancer". The last place I worked had a lot of people working on marine larvae, so they had "cypris", "zoea", "actinula", etc. When you decide on a name and send it to your Local Network Guru, also ask the following questions: What will my machine's full Internet name be (e.g. fiddler.biol.scarolina.edu for the machine at which I'm sitting)? What is my IP address (e.g. 123.234.321.112 as a totally fictitious example)? Is this network subnetted? If so, what's the subnet mask (e.g. 255.255.0.0)? Is there a non-default broadcast address? If so, what is it? What are the IP addresses of three domain nameservers? And, before you start the software installation, do yourself a favor. Open up your machine and take a good look at the network adapter card. Write down any strap or switch options that are set. You'll probably need them later when you do the software configuration of the driver for TCP/IP. ----------------------------------- (5) Installing IBM's TCP/IP Package ----------------------------------- All the documentation comes with the Base Program. The other packages just consist of a folder with disks. It is not initially clear how to proceed, so here's enough to get you going: Begin with the manual "TCP/IP Version 1.2.1 for OS/2 (Refresh): Installation and Maintenance". You install the TCP/IP software first, then the specific driver software for your Ethernet or Token Ring board. There's a nice little configuration program called ICAT (Installation and Configuration Automation Tool). As per instructions, stick in disk 1 and run ICAT from an OS/2 command line. Push the "Install" button first. It will give you the opportunity to install any/all of the options you've ordered (base package, NFS, X-Windows, X.25, and source packages). Check off whatever boxes you want and feed disks as requested. Go ahead and install everything you've got. Once everything has been copied to disk, push the "Configure" button of ICAT. Now comes the fun stuff. I'm assuming you have the documentation, so I'll just give you some hints based on what I did. There's a numbered list of 6 configuration things to do. We'll run down the list. 1. Configure Network Interface Parameters. You probably only have one Ethernet or Token Ring board in your computer, so you only have to fill in half this screen (the other half is for another board - and up to two more on a "Next Screen"). Your IP address is whatever was issued to you by your Friendly Local Network Adminstrator. If he/she told you anything about a "Subnet Mask", enter it appropriately. Leave "Broadast" and "Destination Address" blank (unless you've been explicitly instructed otherwise). For that matter, leave the rest of the screen untouched unless told otherwise. Don't forget to check the little "Enabled" box in the top left corner. When done, press the "Menu" button to return to the main Configure menu. 2. X.25 Parameters. You're on your own here (I haven't done this), but it looks straightforward - stick in your IP address. 3. SLIP Parameters. This is if you're going to use a serial port for access, instead of a network adapter (SLIP = Serial Line Internet Protocol). Fill in the IP address, and the rest is like setting up the dialer in a communications program. 4. Automatic Starting of Services. Again, the following are reasonable defaults if (a) you haven't been told otherwise; and (b) you have the software involved. DO enable the inetd super server - this is one program which runs all the time and spawns off some of the other network service programs on an as-needed basis. This way they don't all have to be started at once. If you want yourself or others to be able to Telnet into this machine, enable the Telnet server (BUT SEE NOTES BELOW - THIS CAN BE A REAL SECURITY RISK). This does not influence your ability to telnet out of this machine to other machines. If you want to be able to access files on this machine from other machines using the FTP protocol, enable the FTP server. This does not influence your ability to use FTP on your machine to access other machines. (SEE NOTES BELOW - THIS IS A POTENTIAL SECURITY RISK). Unless you know otherwise, DO NOT enable TFTP. I lean towards not enabling rexec and rsh unless there's a compelling reason to do so. THESE ARE A REAL SECURITY RISK. Again, this does not affect your ability to rexec or rsh from your OS/2 machine to other machines. If you are going to make a printer attached to your computer available to other computers (i.e. your machine will be a network print server), enable the lpd server. NOTE: To prevent lpd from printing a banner and control file before each document, set lpd to run in the "Foreground" (not via inetd), and type in "-b -c" (without the quotes) in the blank for arguments. This is particularly important if you have a Postscript printer (since the banner and control files are in ASCII, not Postscript, they will mysteriously stuff the printer). If you've got the X-Windows stuff, enable it (leave the "Parameters" as it is). If you're into online typing to people, enable Talk, but honestly, why not just use the phone? Enable the NFS Server if you want other people to access your hard disk (SEE SECURITY NOTES BELOW). Enable NFSCTL if you want to be able to mount other machines' disks (but note that they must allow you to do so). Go ahead and enable the automatic routing server "routed". FINALLY, if you're going to receive mail directly onto your machine, enable "sendmail". If you're already receiving mail on another machine, this is FAR more trouble than it's worth (in my opinion). With the other software you've got, you'll easily be able to read your mail on another machine, so why bother with all the sendmail setup stuff (which is relatively fierce)? 5. Configure Services. I'm going to give hints based on my slightly net.paranoid approach. See the security notes below for some details. Put one and only one entry in the FTP Access Protection: anonymous. If you're doing X-Windows, X Host Authorization gets the name of the machine(s) on which your X "clients" (e.g. main programs) will run. In the X Client Display Variable, enter your OS/2 machine's IP address (or Internet name, whichever). Not the name of the host to which you will be connecting, but this very OS/2 machine's address. Follow the IP address or machine name with ":0" (without the quotes of course). For example, I entered: fiddler.biol.scarolina.edu:0 Fill in the timezone in standard Unixoid format. See page 95 of the manual for some of the more popular timezones. If you will use another machine's printer, enter that machine's name and its printer's name. If you took my advice on rexec, enter nothing in the rexec username and password. Enter nothing in the password field for telnet (BUT SEE THE SECURITY NOTES BELOW). Enter your machine's name in the Hostname field (just the very first part of the name: "fiddler" in the case of "fiddler.biol.scarolina.edu"). Enter the rest of the name in the Domain Name field ("biol.scarolina.edu"). Type in (correctly!) the IP numbers of the (up to) three local nameserver machines your Always Cheerful Network Adminstrator gave you. 6. Routing Information. If you're lucky, you won't have to enter anything in the routing information screen. Your local network will happily figure everything out for itself. If you _do_ need to enter something here, see the local Net Guru (whose cheerfulness may be wearing a bit thin by now). I'm lucky - I haven't had to deal with this. When this is done, go ahead and "Exit" all the way out of the ICAT program, reassuring it that you really do want it to write this stuff to disk as it quits. ------------------------------------------------- (6) Installing the driver for the network adapter ------------------------------------------------- Once you finish with all that nonsense, you will realize that you haven't told the software anything about the network adapter you've got. Time to turn to the "LAN Adapter and Protocol Support Introduction and Configuration Guide". Cram in the LAPS disk, and, from an OS/2 command prompt, start up the "LAPS" program from the floppy. First do the install to copy in the software. Next, go to the configuration part. What you do is simple: pick one from column A and one from column B. In fact, IBM has made it simpler still - there's only one choice in column B (but you still have to explicitly pick it). Choose your network adapter from the Network Adapters list (select and "Add" it). Then choose the only choice (IBM TCP/IP) from column B. You've now declared that your network adapter number 0 (the first one) is of a particular type, and it will run TCP/IP. Now highlight the adapter name in the Current Configuration window and press "Edit". Now's your chance to make sure that the hardware options on your adapter match up with the software's idea of them. Change anything that needs changing. When in doubt, leave it as it was. Notably, you should probably leave the "Network Adapter Address" blank. That number is supplied by the board hardware unless you enter an overriding number here. Once you're done with the configuration, press "OK" and the proper configuration will be copied in. ------------------ (7) Initial tryout ------------------ Are ya feelin' lucky? Hope so. Quit out of LAPS. Do the standard OS/2 Shutdown. Make sure your network adapter is actually plugged into a network. Cross fingers and toes. Start up OS/2. It will take much longer to boot as five zillion networking programs crank up. Lots of them will put screens up as they come on. Once things are up, you can minimize these screens. Meanwhile, they will tell you of your progress. If things really choke and you don't get a boot, well, you knew the job was dangerous when you took it. Get an OS/2 guru to boot from a floppy for you and REM out the line in "startup.cmd" that says "CALL C:\TCPIP\BIN\TCPSTART.CMD". Assuming things more-or-less come up, try things out. First, from an OS/2 command line, try a ping to yourself. In my case, that's "ping fiddler.biol.scarolina.edu". You should get a series of one-liners once a second informing you that you've sent 64 bytes to yourself and received it. Press Control-C to quit that. If, after you enter your ping command, you get nothing (the command just hangs there), you've got a problem: you're unable to find yourself. Check your machine name and Internet number using ICAT, and make sure your network adapter board is properly set up, and the correct parameters are set using LAPS. One thing you'll want to try (I did) is to double-click on the cute little INETD icon. Don't do it. You'll get a textmode screen with Inetd's potential clients listed. That's it. No menus. No nothing. It makes you feel like DOS is back. Press Alt-Tab or Alt-Esc to get the hell out of there. Memorize this, because one day you'll do it accidentally anyway. [Hey, does anyone know how to stop this rather rude behavior?] Try telnetting to your local host. Try an FTP file transfer. Once FTP file transfers work, I advise you to take the following step next, before doing much more playing. -------------------------------- (8) Downloading CSDs (bug fixes) -------------------------------- My system almost-kinda-sorta worked (flakey is the word that comes to mind). Following application of the bug fixes, it works very smoothly. So, to avoid wasting time, apply the bug fixes early. Here's the scoop. 1. For neatness' sake, make a subdirectory called "csd" (well, don't listen to me about it, call it "rosebud" if you want). Do a "cd" to that directory (all this is done from an OS/2 command line). 2. Give the command: ftp ftp-os2.nmsu.edu 3. If that doesn't work ("host unknown") you've got a problem with domain name resolution. Ignore that for now, but fix it later. Try giving the command: ftp 128.123.35.151 4. Log in as user anonymous, with your full login (joe@ace.b.c.edu) as password. Yeah, you don't really have a user name ("joe") since you're on a single-user machine. Make one up. For my machine, for example, I might enter "dean@fiddler.biol.scarolina.edu" (without the quotes). 5. Give the following FTP commands [things in square brackets are my comments, not parts of the commands]: binary cd pub/os2/2.0/patches get tcp2274.zip [base TCP/IP package patches] get nfscsd.zip [if you've got NFS] get pmx02205.zip [if you've got X-Windows] get progcsd.zip [if you've got programming toolkit] get x25csd.zip [if you've got X.25] cd /pub/os2/2.0/archivers get unz50x32.zip [Info-ZIP unzipper for unpacking] bye Of course, this will be out of date soon. Just look for the most recent CSD packages in the directory and snarf them. Likewise for the Info-Zip unzipper. 6. Unpack the suckers. First just run unz50x32. It will unpack itself into the unzip program. Then start unzipping whichever other packages came your way. The TCP Base package is a big sucker. You'll need three high density 3-1/2" floppies for it (no, its parts don't fit onto 1.2 Mb 5-1/4" floppies, I tried). The NFS and X-Windows CSD's will happily go into a subdirectory each on one single floppy (either 1.44 Mb 3-1/2" or 1.2 Mb 5-1/4"). The others, I'm not sure. To unpack the TCP Base package, you first unzip the zip file, leading to three "programs". Unpack each of those onto its own 1.44 Mb 3-1/2" floppy disk. Do so by making the floppy disk your current directory, then running the program from there. For example: b: c:\csd\basecsd1 will unpack the first of the three floppies-worth. Switch disks and continue for each of the other two. For the NFS and PMX ones, just unzip onto a floppy. I did: a: mkdir nfs cd nfs c:\csd\unzip c:\csd\nfscsd cd .. mkdir pmx cd pmx c:\csd\unzip c:\csd\pmx02205 7. Now you've got your CSDs (bug fixes) on disk. You have to first REM out a couple of lines in your startup scripts, then reboot. Otherwise, OS/2 will refuse to let you update programs that are currently running. Using your favorite editor, edit your c:\config.sys. Find the line that runs CNTRL.EXE. Insert REM (followed by a space) before it. Save the file (as Plain Text, if you're asked). I found that I also had to edit the file c:\startup.cmd and REM out the line that reads "CALL C:\TCPIP\BIN\TCPSTART.CMD". Now reboot. Why not do all this before even rebooting once? Because applying the CSD depends on a lot of networking environment that is set up in the main config.sys file, so you've got to have booted with the networking stuff installed but REMed out for the CSD to apply properly. 8. Each CSD has its own handy install script. Stick in the floppy and run the whatever.CMD file. For the Base Package it's basecsd.cmd; for NFS it's nfscsd.cmd; for X-Windows it's installx.cmd (thanks for the consistency, guys). Basically all that these do is copy over a bunch of new versions of programs on top of the old ones. As far as I can tell, they don't meddle with initialization setups. 9. With your trusty editor, remove the REMs from config.sys and startup.cmd. 10. Reboot OS/2 to a far less bugfull networking setup. ------------------- (9) A few reminders ------------------- If you are running the X-Windows server, you need to let the host computer know that you're legitimate. That probably means putting your OS/2 machine's Internet name into /etc/X0.hosts or ~/.Xauthority on your Unix box. If you want to mount part of a Unix box's disk, the Unix machine will need an entry in its /etc/exports file describing what you're allowed to mount. Similarly, your OS/2 system's \tcpip\etc\exports file will have to list systems you allow to mount your disks (SEE SECURITY NOTES BELOW). ---------------------- (10) Security concerns ---------------------- You are now a node on the Internet (assuming you've hooked up to an Internet-worked network). That means you have to be security conscious. You don't have to be an international bank to be chosen as a victim. There really are people out there trying to break into whatever computers they can. You don't want to leave yourself open to that. Furthermore, if your computer is ever broken into, you stand a far better chance of getting sympathetic help if you didn't leave it wide open in the first place. If I leave my house unlocked and someone walks in and takes things, they are still doing wrong, but I'd be more likely to get sympathetic help had I locked the door. I will outline the approach I've taken to setting up our OS/2 systems. I AM NOT A UNIX OR NETWORK SECURITY EXPERT. Just for good measure, I'll say that again: I AM NOT A UNIX OR NETWORK SECURITY EXPERT. I've done enough reading to know that (a) it matters; and (b) security holes can be very subtle. So don't necessarily believe what I'm recommending. I welcome comments (but I will not open a debate on the morality of computer breakins). 1. Enable Telnet but only with the real password option. The default password option offered is very weak. It requires a single password that is readable by anyone who has access to the system. VERY WEAK. But, buried deep is a better solution. On page 72-73 of the Installation and Maintenance Manual is the description of how to set up telnet to require a Unix-style password file. Now, Unix-style passwords are far from hyper-secure, but they're better than a clear-text "password"! Perversely, IBM doesn't provide you with a program to make the passwd file: you'll need to copy an /etc/passwd file from a Unix host. But you've probably got a login on a Unix machine - you can use its password file. Follow the directions to install the passwd file and shuffle in a different version of the login.exe program on OS/2. In general, don't depend on any of the so-called "passwords" that appear in environmental varibles. World-visible passwords are a (bad) joke. 2. Disable incoming FTP except for the very restricted "anonymous" account. Your TRUSERS file should look like this: user: anonymous rd: c:\anonymous wr: c:\anonymous Make sure to create the directory c:\anonymous. Someone can stuff your system by filling disk's c:\anonymous directory with garbage, but that's relatively benign. If that's a problem, remove "c:\anonymous" from the "wr:" field. How can anyone FTP a file into your machine if you don't even let them have ftp write access to "\anonymous"? With this setup, a really trusted user can have an entry in the Unix-style passwd file. Then she or he can telnet into your machine and run FTP on your machine to suck the file in. Don't have anything else in the TRUSERS file. The idea of unencoded passwords is ludicrous. 3. Don't enable the rexecd server. It depends on clear-text passwords in the environment or in the NETRC file. People can Telnet in through the passwd-protected telnet, then execute the command. Same goes for the rshd server. Come on. Do you really want Joe Unwashed-behind-the-ears to be able to do "rexec yourmachine del c:\*"? And then giggle a bit. Yup, that could happen. 4. Don't enable the TFTP daemon "tftpd" unless you really need it for some obscure reason. FTP does the job. 5. Vanilla NFS is well known to be full of security holes. You'll notice the tight security demanded by the Unix host: give it a UID and GID number and that's who you are. Cute. I'd be very wary about giving write permission to my disk. REMEMBER: THERE ARE NO ACCESS CONTROLS ONCE SOMEONE HAS ACCESS TO YOUR OS/2 SYSTEM. No files are protected from reading or deletion. Once someone is into your system, they can happily read any of your setup files in \tcpip\etc (which could [if you're naive] contain real live readable passwords). They can also read your \config.sys and tcpstart.cmd files, in case they missed a password or two. The only people I want to have write access to my system are people who've passed the (really minimal!) test of having logged in past the Telnet-with-Unix-style-passwords. -------------- (11) Good luck -------------- That's about it for now, folks. Read the IBM manuals - they're actually not too bad. Not hold-your-handish, but most of what you need is (somewhere) in there. Best of luck with networking. Maybe we'll ping each other one day...