©1996 - Richard A. Bilancia - All Rights Reserved
published first in the March 1987 issue of UNIX®/World
As I've mentioned in previous columns, XENIX® comes complete with several facilities that are not available in other versions of UNIX®. One of these facilities is 'micnet', a local networking and communication package.
'Micnet' is simple yet powerful communication package that allows separate XENIX® computer systems at a single site to exchange 'mail', transfer files between systems, and remotely execute commands across system boundaries. The computers in a 'micnet' network must be connected with serial (RS-232) communication lines. 'Micnet' is not a replacement for 'uucp', the UNIX® to UNIX® copy utility, primarily because 'micnet' does not support modem use. Nor is 'micnet' a substitute for a true local area network (LAN) that allows files to simultaneously be shared and updated across several connected systems. 'Micnet' only works with computers running XENIX®.
'Micnet' comes with the XENIX® operating system core and does not require the optional XENIX® development system (except for XENIX® on the Tandy 6000).
As outlined above, 'micnet' features fall into three main categories: electronic mail transfer and forwarding; file transfer and forwarding; and remote program execution.
With 'micnet' properly installed for all the computers at a given site, users on any system in the network can send 'mail' to any other user, or group of users, on any other system, or systems, in the network without knowing either the system name[s] of the recipient[s] or path routing to the recipient[s]. All that is required is to know the recipient's login ID or an alias (see the discuss of aliases below).
Similarly, any user can copy any file from any system in the network that is readable by the user to any directory in any system in the network that is writeable by the user.
Thirdly, any user can execute any program on any system in the network by simply indicating the source of the standard input, the name of the remote system, and the program on the remote system to execute. While the opportunities and possibilities of such capability are almost without limit, the primary application that comes to mind is the sharing of output devices (e.g., high speed or laser printers) among all users at a site.
Additionally, another benefit of using 'micnet' when compared to 'uucp' is its relative efficiency. For local applications at a single site, 'uucp' can place a substantial drain on small computer systems. Each time a high speed 'uucp' connection takes place between two machines other applications on both systems can be slowed as a result. One of the primary advantages of using 'micnet' compared to 'uucp' is to minimize that start-up drain on what are generally scarce computer resources. 'Micnet' accomplishes this goal by having a 'daemon' running in background that occasionally wakes-up to exchange files with the adjacent system, as well as conatining a slightly more efficient transfer protocol than 'uucp'.
A single program, 'netutil', greatly eases the system administrator's task of building and distributing the necessary files to begin using the network. However, a fair amount of design and preparation work is necessary before starting. The steps involve: establishing machine names; designing the network layout; connecting the machines together while keeping track of port identifications; drawing of a network topology map; identifying users on each machine, and optionally choosing aliases; creating the 'micnet' files with 'netutil'; distributing the 'micnet' files with floppy diskettes and 'netutil'; starting the 'micnet' daemon with 'netutil'; and finally, testing and using the network.
There are only a few major limitations on the design of a 'micnet' network. They are: (1) as stated above 'micnet' does not support modems, and all communication must be at a single physical site over RS232 lines; (2) each computer in a 'micnet' network can be connected to one or more other computers (in either a "star"\*F A "star" arrangement describes a network in which a single computer is connected directly to all the other computers. or "serial"\*F A "serial" arrangement describes a network in which each computer is connected to one or two other adjacent computers in the form of a chain. arrangement, or a combination of both, as fully discussed in the documentation), but no design can form a "ring" or complete circle; and (3) there can be "...no more than one connection between any two computers in the network."
One of the nicest features of using the 'netutil' program to build a 'micnet' installation is the ability to save the defined configuration of the network (that has been entered on a single system in the network) on to a floppy diskette, and then take that diskette to each of the other systems in the network and reload it into each system without any further modification.
The documentation for designing, installing and testing a 'micnet' network that is distributed with XENIX® is brief but quite complete. Most system administrators should have very little difficulty implementing the system.
Using 'mail' over a 'micnet' installation appears no different to the user than using 'mail' to send a message to another user on the same system. For example, let's assume that user "mary" on a computer with a system name of "contrary" wants to send a message to "jack" on a computer with a system name of "black" regardless of how they are connected. All she needs to do is type:
$ mail jack
Jack, Please send a copy of your latest "report" file
to my
"/tmp" directory. Thanks, Mary
'Micnet' will automatically determine the system name and routing to use to send "jack" the message from "mary".
The command that is used to do a remote file copy over a 'micnet' network is 'rcp'. Copying files from one system to another with 'rcp' is only slightly more difficult than sending 'mail' because the user needs to know the name of the remote system he or she is planning to copy to or from. How Jack would respond to Mary's request is a good example of how to use 'rcp':
$ rcp -m report contrary:/tmp/for_mary
This command copies the file "report" from Jack's current working directory to a file "for_mary" in the /tmp directory on the "contrary" system. The "-m" option is used to send 'mail' back to "jack" whether there was an error or the transfer completed successfully. An additional option, "-u", can also be used to send 'mail' about the 'rcp' command execution to any other user on the network (see your manual for more details). This command will only work subject to proper permissions being set-up in /etc/default/micnet.
Finally, the command that is used to do a remote program execution is 'remote'. If Jack had wanted to send a copy to the system printer on Mary's system, rather than sending a copy to the /tmp directory, he could have typed:
$ remote -f report contrary lpr
and the file would be printed as is on the "contrary" system printer. The "-f" option indicates to 'remote' that the name of the file is "report" that should be used as the input to the 'lpr' program on the "contrary" system. If Jack wanted to format the "report" file with 'pr', he should have typed:
$ pr report | remote - contrary lpr
In this case the "-" option tells 'remote' to send the standard input (the standard output from 'pr') to the 'lpr' program on the "contrary" system. As above, a "-m" option could have been used to send 'mail' back to Jack or using "-u" to someone else. Also as above, the 'remote' command will only work subject to proper permissions being set-up in /etc/default/micnet.
If you are used to using 'uucp' for electronic mail or file transfers among several UNIX® or XENIX® machines, you understand how difficult it can be to keep track of a long path of system names for the various systems with which you communicate. For example, if I wanted to send 'mail' to Dr. Rebecca Thomas about this article, I could do so from my system named "bilanc" with the following:
$ mail isis!hao!sunpeaks!sun!idi!uworld!beccat txtfile
If, however, I had made the following entry into "/usr/lib/mail/faliases" on my system:
beccat:isis!hao!sunpeaks!sun!idi!uworld!beccat
all I would need to type would be:
$ mail beccat txtfile
This kind of aliasing for 'mail' addresses sent via 'uucp' is a side benefit of 'micnet' that can be implemented without implementing 'micnet'. Several other types of aliasing are available, and can be learned by reading the 'aliases(M)' and 'aliashash(M)' manual pages.
While 'micnet' was not designed to be a complete replacement for 'uucp' or a true file sharing local network (like Remote File System (RFS), Network File System (NFS) or STARLAN®), 'micnet' may well be an integral part of a local network of work group computers that need to exchange 'mail' and share files and printing devices.
'Micnet' is not without some potential additional serial output port and cabling requirements if other communication tools are also required. For example, when 'micnet' must be operational between two machines that also need 'cu' access in either or both directions, a second (and possibly a third) serial port and cable might need to be installed between the two machines. Of course, if only one cable and/or port exists between the two machines, 'micnet' can be halted with 'netutil' on both machines, one of the two ports can be appropriately 'enable'd, and 'cu' on the appropriate system can be executed.
Also, 'micnet' cannot be used without 'uucp' to communicate between systems that are connected with modems. 'Micnet' was designed, however, to co-exist with 'uucp' so complex networks that combine the strengths of 'uucp' and 'micnet', including aliasing, can be built quite straightforwardly.
But most important, 'micnet' by itself is easy to set up and administer,
and even easier to use. Good luck with your installation!