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
Date: 13 Jan 93 02:30:42 GMT
Reply-To: dean2@tbone.biol.scarolina.edu (Dean Pentcheff)
Followup-To: comp.os.os2.networking
Organization: Department of Biology, University of South Carolina, Columbia
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...
Newsgroups: comp.os.os2.networking