Francisco A. Camargo (Kiko) <camargo@cs.columbia.edu> (04/23/91)
Hi there,
[VERY LONG MESSAGE]
Given that many people requested a copy of my findings, here goes
the replies about my "UNIX to NOVELL connectivity" question.
It seems that NOVELL 3.11 with LAN Workplace for DOS is the quick and
expensive way to go. However, you will find an interesting discussion
on the subject by Rich Braun, who presents a "low cost solution" to
this problem.
I edited the replies so that they contain page breaks at the appropriate
places for printing these pages into a decent document. My apologies if
I mis-edited something. I hope this summary helps those with similar problems.
/Kiko
camargo@cs.columbia.edu
------------------------------------------------------------------------------
From: ludas@chili.CC.Lehigh.EDU (Dan Schwartz)
I am very interested in whatever responses you receive concerning
connecting unix and novell lan's.
>... a Ethernet link also used by a NOVELL O.S. ? Does this
> requires Windows, or are there other X packages exclusive for
> DOS ?
One product you might like to take a look at is PC-Xview by GSS.
It is an X-windows server (running on the PC) without requiring
ms-windows. It does however require a "comercial" tcp/ip package
like FTP's PC/TCP software. I installed it on with FTP's PC/TCP
and the Clarkson Packet drivers, and got the whole thing to work
for a few minutes before I messed up something in my X-client (on
the Unix box), and hung the whole mess.
/dan
ludas@spot.cc.lehigh.edu
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: bdahlen@zephyr.cair.du.edu (Robert L. Dahlen - U. Denver USA)
I don't have a lot of information, but look into the Packet Drivers
from Clarkson U. and TCP/IP from the National Center for
Supercomputing. And finally KA9Q for TCP over Arcnet, Token Ring,
etc.
This all works on Novel 2.1x. The world changed in Novell 3.11
since servers now pass TCP/IP, but I'm not sure how this effects
everything else.
Robert L. Dahlen - Director, Information Systems & Technology
University of Denver - Denver, Colorado 80208 (303) 871-4385
INTERNET:bdahlen@du.edu BITNET:bdahlen@ducair
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: rbraun@ursa-major.spdcc.com (Rich Braun)
I wrote the following paper on this subject last week. I hope it
addresses some of your issues.
-rich
------------------------------------------------------------------------------
------------------------------------------------------------------------------
A Low-Cost Unix/DOS Network Solution for Software Engineering
By Richard Braun
Copyright (C) 1991
Kronos, Inc. / Waltham, MA
11 April 1991
DRAFT
1. Introduction
As Unix operating systems are increasingly ported to low-cost
hardware platforms, including PC-compatibles and Risc
architectures, demand is rising for ports of existing DOS
applications to Unix. At the same time, demand is also increasing
for the centralization of many corporate functions over a diverse
spectrum of networking protocols and hardware.
Traditionally, the integration of DOS-based systems into a
corporate network has been viewed as a problem of grafting them
into an existing network based on other systems, typically Unix and
TCP/IP. With the widespread acceptance of Novell NetWare and other
PC-based protocols, large numbers of companies will soon run into
the opposite problem: that of grafting TCP/IP into an existing
network of DOS-based systems. This paper discusses a low-cost
method of building an environment for software engineering under
Unix and DOS, combining the features of Novell NetWare and Unix
TCP/IP on a single local area network.
2. Goals
The goals of this project were as follows:
To minimize the impact of new software, hardware, or
procedures on people currently using a NetWare-based LAN;
To bring up several low-cost Unix systems and workstations
for software development;
To provide widely-expected facilities to users of these
Unix systems, including backups, dialup modems, printing,
and electronic mail;
To centralize a base of existing source code, allowing the
direct use of a widely-accepted source code control
system (RCS) by both Unix and DOS users;
To create system-independent procedures for compiling and
building binaries from source code libraries;
To provide full access to all files residing on a series
of Novell servers to Unix users; and
------------------------------------------------------------------------------
------------------------------------------------------------------------------
To allow Unix and DOS users alike to continue using their
native systems without the need for switching between two
systems regularly (which eliminates the two-tube desktop
syndrome and provides user convenience).
At the time these goals were established (December 1990), no
combination of commercial product offerings could meet them. Even
today, no single vendor can meet these challenges.
A NetWare-based solution is presently under development at Novell,
and should be widely available within the next several months. For
several reasons, the combined TCP/IP-NetWare solution presented
herein was selected for use at Kronos, and may be desirable at any
number of other locations.
3. Hardware requirements
The existing network consisted of several thin-wire Ethernet
subnets, each connected to a Novell server which in turn was
connected (through a second LAN interface card) to an Ethernet
"backbone" consisting of two or three fan-out units. Each DOS user
was connected to one of the thin-wire subnets using a LAN card from
one of several vendors.
This solution poses no additional hardware requirements for DOS
users, as it employs a dual-stack packet driver capable of running
NetWare and TCP/IP on an existing LAN card. Unix workstation users
are somewhat more constrained, as they must install a LAN card
supported by their Unix system's TCP/IP device driver. For SCO
Unix on a 386-based PC-compatible, this means installing a LAN card
from 3-Com or Western Digital; Racal-Interlan also claims to
provide a driver for SCO Unix.
DOS LAN cards supported by the Clarkson drivers are:
3Com 501, 503, 505, 523; ARCNET; AT&T StarLAN series BICC
Isolan 4110; IBM token ring; NetBIOS; Novell NE1000 NE2000;
Racal/Interlan NI5010, NI5210, NI6510, NI9210;
SLIP8250; Tiara LANCARD/E; and Western Digital WD8003.
For backups, at least two tape drives are required: one for
backing up the Novell servers, and one for backing up Unix
filesystems. Software could conceivably be written to access a
single, common tape drive, but backups take long enough in the
Kronos environment that a multiple-drive approach was preferred.
The server used to export Novell files via NFS consists of a
dedicated 386-based PC configured with 640K or more of ram, a small
hard disk, and any Ethernet card supported by the packet drivers.
The Proteon cc:Mail gateway currently requires two dedicated PCs,
though this requirement may be changed if some of this code is
ported to run under Unix, accessing cc:Mail directories via NFS.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Using printers between Unix and DOS was most easily implemented
using one of many available multiplexing print buffer units, sold
for about $200. Other solutions will present themselves over time;
this solution is not ideal, because print jobs cannot be cancelled
once they are sent to the buffer (which holds many minutes' worth
of output), and the user cannot query whether a job is finished.
4. Software requirements
Most of the software is available free of charge from Clarkson
University and other places via the Internet. The following
components are used:
Packet drivers version 7 from Brigham-Young University and
Clarkson
CUTCP version 2.2D, a DOS TCP/IP package from Clarkson derived
from NCSA Telnet
PC/IP, a DOS TCP package from Carnegie-Mellon University and
MIT
IPXPDI version 2.01, a packet-driver interface for NetWare
from BYU (now included with the SOSS package)
SOSS version 3.1, a DOS NFS server derived from source code
originally developed at Lawrence Berkeley Laboratory by
See-mong Tan
RCS version 5.5, a widely used Revision Control System
originally developed by Walter Tichy and now distributed
by the Free Software Foundation
Gnu diff version 1.15, a file-comparison utility used by
RCS and distributed by the Free Software Foundation
A public-domain cc:Mail gateway distributed by Proteon
d2x and x2d, DOS/Unix conversion programs written at Kronos
dmake version 3.6, a Unix-compatible Make facility for DOS
Not all features of PC/IP are used; the Clarkson Telnet program
provides a much broader set of features, for example, than PC/IP
Telnet.
Source code to two of these items (SOSS and RCS) was modified at
Kronos to support this engineering environment. These
modifications are relatively minor (less than one man-month of
work) and are made available via the Internet.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
5. Documentation
Documentation for each of these packages is provided in the form of
text files included with each distribution. A synopsis of what is
provided is as follows:
Packet drivers: an 11-page manual plus a 3-page
description. A separate summary is also provided for each
supported LAN card.
CUTCP: an 80-page manual.
PC/IP: a 60-page manual.
SOSS: a 5-page user guide plus a 5-page description.
RCS: a "man page" for each of the 8 utilies, plus a short
introduction guide.
The Proteon e-mail gateway: an 8-page description plus a
4-page installation guide.
dmake: a 44-page manual.
6. Putting it all together
The first step is to retrieve the distribution kits for each
software package. You will then need to map out your Novell
network and determine which DOS users need to have access to the
TCP/IP subnet. (Or, of course, do the opposite if you're adding
Novell systems to an existing TCP/IP network.) Most of these
packages are for DOS; you should place DOS executables on a Novell
server accessible by all systems.
6.1 Mountable filesystems
One or more dedicated DOS systems need to be configured to run SOSS
(you will want more than one system only if the single unit becomes
a performance bottleneck), and the e-mail gateway currently
requires at least one system. Set up the appropriate packet driver
on these systems, configure NETDEV.SYS and add a device line to
CONFIG.SYS. Create an AUTOEXEC.BAT file on the SOSS server system
which does the following:
Run the packet driver
Load IPXPDI
Load NET3 or NET4 (the NetWare shell)
Log into the NetWare server (you will need to use KEY-FAKE,
a small DOS utility provided with SOSS, to type in any
required password.)
Map the desired filesystems to a DOS drive letter
Castoff broadcast messages from Novell servers
Invoke SETCLOCK to synchronize with the time server
Run SOSS
A minor inconvenience exists for users attempting to edit or print
text files across machine architectures. The line separator for
Unix text files is linefeed only, whereas DOS uses
carriage-return/line-feed. A conversion utility (d2x and x2d, now
provided with SOSS) must be run when such files are referenced
across the great Unix/DOS divide.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
6.2 Remote TCP/IP login
On each user's DOS system, create a CONFIG.TEL file to define its
IP address and the addresses of your site's gateways, name servers,
and so on. Make sure each DOS system has access to TELBIN.EXE, and
an environment variable CONFIGTEL defined as the location of its
CONFIG.TEL file.
6.3 Source code development
To use the RCS source code control system, you must locate source
code directories on filesystems accessible to everyone. Using the
public-domain approach described herein, you would place them on a
Novell server, because DOS users cannot mount Unix filesystems
directly; alternatively, you can buy Portable NetWare for one or
more of your Unix systems and store RCS files there, or buy PC-NFS
for each of your DOS systems.
The dmake utility has proven extremely helpful in creating
platform-independent "make" files, which can be run under both Unix
and DOS. Many of the make utilities sold with DOS-based compilers
lack the more advanced features which Unix make utilities provide.
6.4 Electronic mail
The e-mail gateway for cc:Mail requires considerable configuration
information, which is beyond the scope of this paper. cc:Mail
sells an SMTP gateway product at a considerable price; a
public-domain offering from Proteon may prove adequate for your
needs.
6.5 Backups
At the time of this writing, a typical 330-Mb fixed disk drive
sells for about $1000; tape drives actually cost about the same,
per megabyte. This has made it economical to set up a system
whereby daily incremental backups are placed on a fixed disk by a
'cron' script performed by each Unix system. Full backups are
performed to tape, on a schedule which is determined by amount of
space available on the fixed drive and by the number of
modifications made within each filesystem.
SCO Unix is shipped with a shell script called 'cbackup' (in
directory /usr/lib/sysadmin), which uses 'cpio' to create the
backup image. Some fairly minor modifications can be made to this
script in order to allow for unattended disk-to-disk backups.
Users of 'cpio' should be aware that the ASCII header information
option, '-c', must be used for compatibility of backup images
across different machine architectures.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
6.6 Modems
Two modem pools were created: one group on a Unix system, and
another on the Novell network using an asynchronous communications
server. If a single pool is desired, there are two possible
options: add a port selecter between the modems and the computers,
or add software to the Unix systems which would allow transmission
of IPX datagrams via the modem lines. The latter is much more
complex than simply creating a second modem pool, so it was not
done in our case.
6.7 Printer service
A similar problem presents itself here: the Unix and Novell
network print services are incompatible, and a fair amount of
coding would be required to create a bidirectional network
interface. Low-cost hardware products are available, however,
which allow more than one computer to access a single printer.
This approach was taken at Kronos.
7. Some suggestions and/or open issues
CUTCP supports the use of the bootp protocol to configure IP
addresses and other information for each DOS user. By bringing up
a bootp server somewhere on the network, the network administrator
can escape the task of updating TCP configuration files on each PC.
A means of synchronizing time between Novell servers and
TCP/IP-based Unix systems should be implemented; this may be
resolved in future releases of Novell's server software. PC/IP
provides a SETCLOCK program for setting a PC's date and time from
a TCP/IP time server, and Novell's login program automatically sets
the time from a Novell server.
The cc:Mail gateway has not yet been installed and tested; this
procedure is quite complex.
Ideally, an engineer running a compiler on any system could build
binaries for any other system on the LAN. This requires
cross-compiler products which do not exist today, though this may
happen at some time in the future. The Gnu C compiler can be
configured for cross-compilation on most Unix platforms, but it
cannot create DOS binaries at this time. A recently-developed DOS
extender for Gnu C is incompatible with Windows and other DOS
software, and no company produces a Unix-based product for
producing binaries executable under a DOS extender.
8. Reliability
A popular perception is that "you get what you pay for", and that
free software is buggy and unsupported. This environment contains
hundreds of thousands of lines of free software, so an
administrator is wise to question its ease of use, maintainability,
and reliability.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
An argument in favor of free software, mainly developed in
university environments, is that it provides a large base of
support tools which allow companies to get on with the business of
designing applications, rather than developing basic tools.
Universities also provide a harsher field-test environment for
security problems, as some of their users are more likely to spend
time looking for holes. (The Clarkson TCP product provides an
example of this: NCSA Telnet, as distributed, will allow any user
on the network to view, modify, or delete files via a
terminate-and-stay-resident FTP server, unless the PC user
explicitly creates a password file. Clarkson's modification plugs
this hole.)
This environment is just now entering daily use at Kronos; as time
goes by its reliability will be tested and improved.
9. Where to get it
A centralized place for obtaining the software described herein may
be established in the future. In the meantime, it may be retrieved
from Internet sites as follows:
Product System Directory Contact
--------- ----------- ----------- ----------------------
PC/IP husc6.harvard.edu pub/pcip
CUTCP omnigate. pub/cutcp/ cutcp@omnigate.
clarkson.edu v2.2-D clarkson.edu
Packet sun.soe.clarkson. pub/ka9q nelson@clutx.clarkson.
drivers edu edu
RCS(unix) prep.ai.mit.edu pub/gnu
RCS(DOS) spdcc.com pub/sos few@gupta.com,
rbraun@spdcc.com
diff(unix) prep.ai.mit.edu pub/gnu
diff(DOS) vulcan.phyast. pub/msdos
pitt.edu
dmake watmsg.waterloo. pub/src dennis@watmsg.
edu waterloo.edu
SOSS spdcc.com pub/sos rbraun@spdcc.com
d2x spdcc.com pub/sos rbraun@spdcc.com
Gateway monk.proteon.com pub/novell acm@relay.proteon.com
The procedure for retrieving files on the Internet is:
ftp <system>
(user) anonymous
(password) <myname@myhost>
binary
cd <directory>
get <files>
------------------------------------------------------------------------------
------------------------------------------------------------------------------
10. Security issues
The SOSS server contains no security features; any file accessible
to the server can be read or written by any remote NFS user.
Several man-weeks of effort would be required to add user ID, group
ID, and file-mode checking to SOSS. Alternatively, one could
purchase Novell's just-announced NFS server product, which contains
these features.
RCS allows users to specify a user-name different from their own
when performing update operations. If this presents a security
problem, you may wish to modify RCS source to eliminate the "-w"
command line option.
When retrieving software from the Internet, one must be aware of
potential "trojan horse" or "virus" security problems. The most
important precaution is to retrieve software from trustworthy
archive sites, such as those recommended here.
11. Caveat
This information is subject to change without notice. It may or
may not be helpful for your own purposes.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: keith@ca.novell.com (Keith Brown)
>Can a Unix workstation operate as a DOS file server ?
There are a number of ways this can be done. Our (the Novell) way
would be to use a product called the LAN WorkPlace for DOS which is
our TCP/IP product for MS-DOS based PCs in conjunction with a piece
of NFS client software from Beame and Whiteside. The B&W NFS client
uses the TCP/IP transports in the LAN WorkPlace to allow PCs to map
virtual drives to areas of a UNIX machines file system using NFS.
The LAN WorkPlace also gives you lots more TCP/IP functionality.
Other ways to do this would be using Suns PCNFS and so forth.....
> And the other way around (i.e., a Novell server operate as a Unix
> NFS) ? What happens with file names and the like ?
No problem. If you use NetWare v3.11 we have a product called
NetWare NFS which provides the server with NFS server capability
aswell as LPD services and an FTP server. We support full NFS file
system semantics through the use of an NFS namespace in the NetWare
file system (ie, all files have UNIX attributes and can have up to
255 character file names). We have algorithms to map the long
UNIX/NFS filenames into 8.3 filenames digestible to DOS systems.
> Can a DOS machine establish a XTERM connection with a UNIX
> workstation through a Ethernet link also used by a NOVELL O.S. ?
> Does this requires Windows, or are there other X packages
> exclusive for DOS ?
There are a number of third party X-Servers available for use with
the LAN WorkPlace. My favorite is a product called XVision from a
company called VisionWare. It does require Windows 3.0 to run. I
can give you the phone numbers and such if your interested. There
are also others....
> What degree of peer-to-peer connectivity is possible to achieve
> in this multi-platform environment ? Are there database packages
> available to support the development of such applications ?
Today, network database packages tend to have a peer to peer
client/server architecture. There are lots available for NetWare
but most of these are for DOS<->NetWare client/server. There aren't
to many for UNIX<->NetWare client/server right now. Now we have
TCP/IP available in NetWare v3.11 it is likely that many database
companies will be porting their database engines from UNIX to
NetWare (ie. making them available as NLMs). Oracle are among the
forerunners in this at the moment, as far as I can tell. A good
contact at Oracle is Doug Laird on 415 506 2804.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
> What kind of products are available in the market that will
> support these kinds of connectivitys ? What about Netware VAPs ?
> Are there any NOVELL products ready to install ?
When it comes to VAPs I guess BTrieve makes the most sense to write
database apps to (it comes free in the NetWare 286 OSs). We also
have BTrieve available in NLM form for our 386 operating systems.
Also as NLMs we have NetWare SQL which does a similar job to
BTrieve but is more "standard" as far as standards go in the
database world. NetWare SQL is an additional product though. Both
BTrieve and NetWare SQL are strictly DOS<->NetWare right now. The
latter may one day become TCP/IPed at some stage.
>
> Please, note that although I may need to have the DOS machines
> working as terminals of the Unix system through the ethernet
> media, I also need them running standard Netware sessions, and
> accessing an existing file server.I may, however, decide to
> upgrade the Netware 2.15 to 386/3.1 if that turns out to be
> required.
The LAN WOrkPlace for DOS gives you VT220 terminal capability to
the UNIX machines via TELNET. In fact it contains two telnet
clients, one for Windows 3.0 and one for your ordinary DOS user.
The LAN WorkPlace runs concurrently to NetWare *or* standalone. You
don't even need a NetWare server to run LWP if you don't want.
All of the above is biased towards using Novell products for the
various things you asked about. As with everything in this
industry, other vendors have other ways of doing most of the above,
although I don't think you'll find another single source vendor who
can do all of the above. Even we have to borrow Beame and Whiteside
for NFS client capability :-).
Hope this has been useful,
Regards,
Keith Brown Phone: (408) 473 8308
Novell San Jose Development Centre Fax: (408) 433 0775
2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: Terry Duncan
<tduncan%secola.Columbia.NCR.COM@mathcs.emory.edu>
One way you can connect Unix with NetWare is through Portable
NetWare. NetWare runs as a set of processes on top of Unix with
complete NetWare 3.1 compatibility. You would never know the
difference between a PNW server and a Native server except for
performance. PNW is slower because the machine is not dedicated to
doing NetWare but you have the Unix functionality. It also comes
with a utility called Netware Virtual Terminal which allows PC's on
the network to be used as virtual terminals to log in to the unix
machine over the ethernet. NetWare file information is stored in
an access data base which contains the unix, dos, and macintosh
file names along with access rights. Novell does not sell PNW but
OEMs it to hardware manufacturers like NCR, and Data General.
Another solution would be to buy NetWare 3.11 and the NFS NLM.
This allows unix boxes with NFS to mount a NetWare volume. I
imagine the file names are mapped in the same sort of way as in
PNW. This is not an inexpensive solution. I think the NFS NLM is
$5000 in addition to the cost of 3.11.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: janetp@ca.novell.com (Janet Perry)
IN order to connect UNIX machines and PCs, you have several
options. If you wnawant the UNIX machine to be a server for your
PCs, you can either use something like PC-NFS, which let the PCs
mount NFS volumes, or some sort of terminal emulation program,
which lets you use ftp. Novell makes a telnet/ftp program called
LAN WorkPlace for DOS that will work in conjunction with NetWare to
do ftp. Several other companies like Wollongong, FTP SoftWare and
Racal/Interlan also make telnet packages. There are also solutions
like this in the public domain (Clarkson packet dirvers, Kermit,
NCSA Telnet, etc).
If you want your UNIX host to be able to access files on a NetWare
server, then you would want to use NetWare 3.11 and our Netware NFS
NLM. This makes the NetWare server look like an NFS volume to the
UNIX workstations. The UNIX user mounts volumes in exactly the
same way he would if they weer volumes on UNIX machines. But they
interact with NetWare much better security and they are residing on
the NetWare server. NetWare 3.11 also supports multiple name
spaces which means that you can have UNIX, OS/2, DOS, and Macintosh
names for the same file.
Please let me know if you have other questions about these
products. You might find that the Novell listserver would be a
good place for you to get more information about Novell and related
issues. To subscribe, send a one line mail message to
listserv@suvm.acs.syr.edu that says SUBSCRIBE Novell (your name).
In a couple of days, you will be added to the listserver and
messages from all over relating to Novell will appear in your
mailbox. Right now they run about 50 messages a day. This forum
is more technical than the Novell newsgroup and you might find it
helpful to subscribe. I will be happy to send you more information
about the products I talked about.SSend me your USMail address and
I'll get them out to you.
Janet Perry
Mgr, Higher Ed Programs
Novell
415-975-4480
janetp@ca.novell.com
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: lowell@techbook.com (Lowell Brusnon)
I am faced with a similar problem and am interested in what you
find out. We have advanced netware 2.15 running on a 386 (it was
cheaper than the 386 netware stuff and we didn't need the added
features). Many of the engineers would like to have a command line
mail facility like unix while others want a fancy tsr pop up thing.
We have tried 3 different mail systems and are not happy with any
of them. Only one of them offered a UUCP gateway. At another
company, I once had a SUN 386i running an ethernet card for
connecting to the novell server while it also had the standard
ethernet interface on another line running nfs. That was as close
as I came to running on both networks simultaneously. Good luck.
lowell@techbook.COM ...!{tektronix!nosun,uunet}techbook!lowell
Public Access UNIX at (503) 644-8135 (1200/2400) Voice: +1 503
646-8257
Public Access User --- Not affiliated with TECHbooks
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Sender: news@midway.uchicago.edu (NewsMistress)
Unix workstation can act as an NFS file/print server, as long as
you have the proper PC-NFS client software to allow you to access
those services. Novell Netware 3.11 (386) has an expensive ($5k
list) NFS NLM which turns your netware server into an NFS
file/print server for other (Unix) hosts. I don't believe there is
a way to mount a remote drive onto an Netware server. NFS resolves
the file names as they resolve them (whatever way they do it) and
on the novell file server, if you add namespace for it in your 3.11
server, it will store the file name and pointers separately.
> Can a DOS machine establish a XTERM connection with a UNIX
> workstation through a Ethernet link also used by a NOVELL O.S. ?
> Does this requires Windows, or are there other X packages
> exclusive for DOS ?
Sure. We're in the process of doing this now. On the DOS side, we
have a netware server on the backbone using ethernet_II packets
rather than the normal ethernet 802.3 packets, and our clients are
using public domain packet drivers (these things are protocol
stacks, which receive packets and places them in their assigned
stack, depending on the type field in the ethernet packet, hence
the use of ethernet_ii), BYU IPX shells that recognize the packet
drivers, and TCP programs that recongize the packet drivers (there
are a few places that provide these, like clarkson). Basically this
allows you to run telnet/rlogin/ftp while you're still connected to
your novell server (you don't have to be connected). Of course,
this allows you to run X-windows if you have a package that will
work with the packet drivers, but it really isn't necessary. GCC
tech. makes a program called PC-Xview/16 and Xvision which are DOS
and MSWindows versions of X-windows for PCs, respectively (I
personally don't use these but they do get some praise from other
users). On the UNIX side, you just have to make sure that you are
on the same ethernet as the novell server. With the TCP programs,
since novell doesn't provide the workstation with an IP number, you
have to figure out a way to get them assigned, such as hardcoding
them into the program, using bootparam or rarp to assign the IP
address (I'm using one of our unix workstation to do rarp, and
there are PC based versions of these programs that might require a
dedicated PC).
> What degree of peer-to-peer connectivity is possible to achieve
> in this multi-platform environment ? Are there database packages
> available to support the development of such applications ?
The fact that it's a client/server based system makes peer-to-peer
diffficult to do. A company called Fresh Technologies does some
really nice peer-to-peer stuff (allowing remote
printers/modem/control on/of other PCs, allow mapping local drives
onto other peoples computers, all with separate programs for each).
------------------------------------------------------------------------------
------------------------------------------------------------------------------
> What kind of products are available in the market that will
> support this kind of connectivity ? What about Netware VAPs ?
> Are there any NOVELL products ready to install ?
Not sure about VAPs. NLM seems like the way to go these days,
since they can be loaded and unloaded without taking the bloody
server down all the time to add or remove stuff.
> Please, note that although I may need to have the DOS machines
> working as terminals of the Unix system through the ethernet
> media, I also need them running standard Netware sessions, and
> accessing an existing file server. I may, however, decide to
> upgrade the Netware 2.15 to 386/3.1 if that turns out to be
> required.
It's not, although it a hell of a lot easier doing a reconfig on
the 386 server than a 2.15 server. If you can get 3.11, get it and
be happy.
Bob Kusumoto | I just come from the land of
kusumoto@chsun1.uchicago.edu | the sun/ from a war that must
kusumoto%chsun1@uchicago[.bitnet] | be won in the name of truth.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Sender: news@csl.dl.nec.com (CCSL News--cjk)
Hello. This is probably something that gets asked here quite often
so if you'd like, please respond via e-mail.
About a year ago, I setup NetWare 2.15, econfiged, and ran the
Clarkson packet drivers so that we could use Clarkson's version of
NCSA Telnet and other network goodies. All was quite simple and
works very well.
Now, I am working elsewhere and will be setting up a NetWare 3.11
network and I need the same connectivity plus maybe a few more
things like NetWare NFS. v3.11 claims to support TCP/IP
connections. Does this mean that the TELNET software and other
goodies are compatible without econfiging now? Is the process for
setting up pretty much the same as before?
Any help on this as well as any other niceties, not-so-niceties
about 3.11 will be greatly appreciated.
--- Cornell Kinderknecht
cornell@csl.dl.nec.com
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: dougs@claude1.rchland.ibm.com (J Doug Smith)
Contact Kelly McDonald at BYU (kelly@dcsprod.byu.edu). He's who
wrote most of the stuff. There are newer versions (I'm not sure
what the current version is) but at last word, they could no longer
distribute it. Evidently, they licensed it to another company to
sell, and they were only allowed to distribute it to departments on
their own campus. They were negotiating on this point, though.
Doug Smith
IBM Rochester, Dept. 43K
dougs@rchland.iinus1.ibm.com
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: keith@ca.excelan.com (Keith Brown)
> [NetWare] v3.11 claims to support TCP/IP connections. Does this
> mean that the TELNET software and other goodies are compatible
> without econfiging now? Is the process for setting up pretty
> much the same as before?
Yes and no! If you set things up the way you did before then not
much has changed. Clarkson is still maintaining the packet driver
distribution. BYU are still making their packet driver shell driver
available and the "Whether to ECONFIG or not to ECONFIG" issue
still serves to confuse a large number of users and administrators.
However, things have moved on in the last few months and we,
Novell, have now introduced a substantial array of new products
supporting TCP/IP standards at both the server and client systems.
Starting with the server, the TCP/IP support bundled into 3.11
gives you the following features when used by itself. These are:
1) IP routing and subnet routing between multiple LAN interfaces
plugged into the server.
2) The ability to encapsulate the server<->server IPX traffic
inside IP datagrams (actually UDP datagrams) for carrying over an
IP only backbone or WAN.
3) Network management using the Simple Network Management Protocol.
The entire TCP/IP stack is manageable from any SNMP management
console supporting the MIB 1 standard. Just in case you don't have
such a console, we provide you with one running as an NLM also.
4) Provision of the underlying Internet Protocol support for other
NLMs that use TCP/IP to communicate with peers across the network,
NetWare NFS being a good example of such an NLM set.
In addition, we just broke the champagne bottle over NetWare NFS
which is an NLM set that provides NetWare v3.11 with an NFS server
capability, an LPD server capability (distributed printing UNIX
style) and an FTP server capability. The first fork lift truck
laden with pallettes of NetWare NFS went careering out of the
warehouse yesterday in fact.
Finally, we just released a new media independant version of our
TCP/IP client solution for DOS workstations, namely the LAN
WorkPlace for DOS. It can be used standalone or in conjunction
with NetWare and uses the Open DataLink Interface (ODI) driver
architecture at the client in order to support multiple protocols
and datalink encapsulations through a single LAN adapter card.
You'll find these drivers in the LAN WorkPlace package or, if you
already have NetWare v3.X, you'll find them in a subdirectory
called "DOSODI" on the SHGEN-1 disk, which is now the WSGEN disk in
v3.11.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
The LAN WorkPlace itself contains lots of good stuff, including
support for the usual set of TCP apps (Telnet, FTP, R-Utilities
etc....) and a set of these apps specifically designed
for the Windows 3.0 environment if your a point and click type. The
LAN WorkPlace also contains the "client piece" of the tunnel,
allowing the workstation<->server IPX traffic to be encapsulated
in UDP/IP datagrams. Now that we have unleashed this little lot
onto the world at large, the Novell San Jose group is now cranking
on even more goodies for the TCP/IP and standards oriented
communities. Watch this space....
Keith Brown Phone: (408) 473
8308
Novell San Jose Development Centre Fax: (408) 433
0775
2180 Fortune Dr, San Jose, California 95131 Net:
keith@novell.COM
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: Jons@cup.portal.com (Jonathan S Spangler)
> In addition, we just broke the champagne bottle over NetWare NFS
> which is an NLM set that provides NetWare v3.11 with an NFS
> server capability, an LPD server capability (distributed printing
> UNIX style) and an FTP server capability. The first fork lift
> truck laden with pallettes of NetWare NFS went careering out of
> the warehouse yesterday in fact.
Yeah Novell!
do you know *where* that fork lift was headed? Do you distribute to
the big boys first? (Micro-D, Merisel, TechData)?
>... The LAN WorkPlace also contains the "client piece" of the
> tunnel, allowing the workstation<->server IPX traffic to be
> encapsulated in UDP/IP datagrams.
When you say "client piece", are you refering to just to the
mechanism that allows both protocol stacks to be loaded
simultaneously right? This is not the same as the client piece that
comes with PC-NFS that allows me to "mount" a drive from an NFS
server and see that drive in my native DOS (If I understand this
correctly.)
Aloha,
Jonathan
jons@cup.portal.com
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: sph@logitek.co.uk (Stephen Hope)
jbrown@locus.com (Jordan Brown) writes:
> I'm trying to make a multi-protocol-stack setup work, and not
> having much luck, so I'd like to chat with others who might have
> fought the same battles. The general idea is to run Netware
> (2.15) over the Clarkson packet driver using BYU's IPX.COM.
> I have two network cards I've been playing with 3c501 and 3c505.
> The packet drivers are hot off the press, version 9. The IPX.COM
> (actually PDSHELL.OBJ) is v2.01, from 04/89. I'm not running any
> other network software, though of course that's the goal. It all
> "plugs and goes", but pretty quickly grinds to a screeching halt
> and hangs. Running a different IPX package (Hughes LAN Systems
> ProLinc) on the same machine over the same network cards to the
> same server works like a champ. Is there a newer version of BYU's
> stuff? I dug around there with anonymous FTP and didn't find
> anything newer. Are the 3c501 and 3c505 Clarkson drivers just
> flakey? Anyhow, if anybody's worked with the BYU stuff,
> especially with 3c501s or 3c505s, I'd like to talk about it.
> Tnx.
I had lots of problems with a 3c505 on Version 7 / 8 packet
drivers. The same thing happened with V9, until I tried setting the
-d (no DMA) flag. This seems much better. The machine is a Wyse
3225 25MHz 386. Pity about not using the slave 80186 CPU on the
3c505 card tho.
Stephen Hope
------------------------------------------------------------------------------
------------------------------------------------------------------------------
From: sardella@strfleet.gsfc.nasa.gov (Tom Sardella)
Many thanks to all those who responded to my request for help on
the current status of the EXOS product. My main concerns were the
continued support of this product (updates, new licenses, etc.) and
getting a legal copy of the last released version. The bottom line
is that Novell and Federal Technology Corporation (FTC) are
currently negotiating for the rights on the software product and
that FTC hopes to provide the support that we need. I guess we'll
have to wait and see what happens.
The following points were brought up in the responses and in other
research I have done:
1. EXOS software a "dead" product
We weren't the only people confused about the state of this
product. Many people, including ourselves, thought that
EXOS was placed in the public domain when Novell took over
Excelan. We even had someone at Novell tell us in December,
1990, that this was the case. Representatives from both
Novell and FTC now tell us that they are negotiating to turn
the product over to FTC.
2. Excelan Hardware Support
FTC does provide continued manufacture and support of the EXOS
boards. We have had no problems to date with this support
that I am aware of.
3. Use of EXOS code in Novell products
We acquired a copy of "LAN Workplace for DOS 4.0" and they
are still using the EXOS NET code on an EXOS 205 board.
One thing I'm still confused about is what is the latest version
and what do the version numbers mean? We originally started with
V3.2. Avnish Aggarwal, who used to work for Excelan and now works
for Novell, says the latest version is 4.Na. The version we got
with LAN Workplace is 4.Ca. The "Na" and "Ca" suffixes seem odd.
What we think we can do about the licensing problem at this point
is to go ahead and buy all the LAN Workplace licenses we need and
then run NET on our Multibus EXOS 201 boards rather than the PC
EXOS 205 boards. The license agreement states that you can run
object code on one licensed machine at a time, but they don't
distinguish what a "machine" is. Are there any legal experts out
there?
It looks like our news server is OK now, so I can accept further
postings on this subject.
Tom Sardella
Network Control Systems Branch, Code 532
NASA/Goddard Space Flight Center
----------------------------------------------------------------------------