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: <1jkok7INNenq@shelley.u.washington.edu> Date: 20 Jan 93 23:52:39 GMT Reply-To: dean2@tbone.biol.scarolina.edu (Dean Pentcheff) Organization: Department of Biology, University of South Carolina, Columbia Lines: 717 ============================================================================= 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 Jan 20 1992 Minor hints on getting most recent CSDs from Hobbes Jan 12 1992 Removed incorrect advice to fix up XWindow host X0.hosts file. 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. Following is the scoop on how to do this. DON'T BE INTIMIDATED BY THE LENGTH OF THIS SECTION! Because the CSDs change with time, this section is verbose to cover different contingencies. It's really quite straightforward in practice. Install the bug fixes - you'll be very happy you did. 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" or "network unknown") you've got a problem with domain name resolution. Maybe routed.exe isn't running? 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 something like the following FTP commands [things in square brackets are my comments, not parts of the commands]: binary cd pub/os2/2.0/patches get tcpcsd.base1.zip [base TCP/IP package patches] get tcpcsd.base2.zip get tcpcsd.nfs.zip [if you've got NFS] get tcpcsd.pmx.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] get tcpcsd.txt [description file which may be there] 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. You should also check the directories "/pub/os2/new" and "/pub/uploads": new uploads go there first and may not have made it to the patches directory yet. If there are several different CSDs for products you have, download them all. Unpack them (see below) each separately on your machine and check the comments in the installation scripts for the latest date. 6. Unpack the suckers. First just run unz50x32. It will unpack itself into the unzip program. Each CSD release seems to be slightly differently packaged, so I'll just give some general guidelines here. You can probably install them from your hard disk, without having to copy them onto floppies (though they are usually designed to be installed from floppies). Make a subdirectory for each type of CSD (for example, I made subdirectories "base", "nfs", and "pmx") under the directory where you have the zip files. Then unpack each bundle into its appropriate subdirectory. For example, to unpack the Base packages above, I'd do the following: mkdir base cd base ..\unzip ..\tcpcsd.base1 ..\unzip ..\tcpcsd.base2 Normally, the unzipping leads to the creation of 5-50 updated programs and files, one of which is an installation script (ending in ".cmd"). In some cases, the zip files will unzip into one or two monolithic ".exe" programs. These aren't really standalone programs, but are self-unpacking zip files. If, when you're done unpacking the first level of zip files, you only have one or two huge ".exe" files and you DO NOT HAVE ANY FILES THAT END IN ".CMD" (i.e. you don't have an installation script yet), check to see if the couple of huge programs are actually zip files in disguise. To do that, run the listing function of unzip.exe. For example, to check a hypothetical file "basecsd.exe", try running: ..\unzip -v basecsd.exe If the unzip program barfs, it's not a zip file. If you get a nice listing of lots of files, you can unzip the archive by simply running the program. For example: basecsd Don't do any of this fussing if there's a ".cmd" file in the directory from your inital unzipping - that's probably the installation script which will take care of the next level of unzipping for you. 7. Check the installation scripts. I've found two types. One is a pretty elaborate script that quite neatly checks your system out and installs the CSDs from the hard drive directory. These longer scripts are over 100 lines long. If there are just a few files that need copying, there may be a short script instead. In some cases, these short scripts are "hardwired" to copy from the A: drive (tacky!). A quick edit of any offending lines takes care of the problem. For example, changing the line: copy 'A:nfsctl.exe' BASE'\bin\nfsctl.exe' to read: copy 'nfsctl.exe' BASE'\bin\nfsctl.exe' converts the command so that it will run from the hard drive instead of needing to be put on a floppy. 8. Now you've got your CSDs (bug fixes) on disk, ready to install. 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. 9. Each CSD has its own handy install script. Go to the each CSD's subdirectory and run the something-or-other.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). Or it may be called something new and exciting. 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. [Late note on that - one of the newer CSDs does install a new xinit.cmd, but quite politely informs you that it is moving your old one to "xinitbak.cmd".] 10. With your trusty editor, remove the REMs from config.sys and startup.cmd. 11. Reboot OS/2 to a far less bugfull networking setup. ------------------- (9) A few reminders ------------------- 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...