ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / MISC / NETWORK / SOSS31.ZIP / DOC / UNIXDOS.TXT < prev

Wrap

Text File | 1991-04-11 | 16.5 KB | 418 lines

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