Category : Network Files
Archive   : SOSS_SRC.ZIP
Filename : UNIXDOS.TXT

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;

Page 2


- 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.

Page 3



Sharing 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 Univer-
sity 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.

Page 4


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.

Page 5




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.

Page 6


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

Page 7


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 [email protected].
drivers edu edu
RCS(unix) prep.ai.mit.edu pub/gnu
RCS(DOS) spdcc.com pub/sos [email protected],
[email protected]
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 [email protected]
d2x spdcc.com pub/sos [email protected]
Gateway monk.proteon.com pub/novell [email protected]

The procedure for retrieving files on the Internet is:

ftp
(user) anonymous
(password)
binary
cd
get

Page 8


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.