+.TL
+Network System Manual
+.AU
+Eric Schmidt
+.AI
+May 1979
+(Revised March 1980)
+.SH
+Introduction
+.LP
+This documentation should be read by people responsible for
+maintaining the network (and the systems it runs on).
+It is divided into the following sections:
+.DS
+Maintaining the Network
+Setting up the Network
+Future Plans
+For Berkeley
+Bugs
+.DE
+Besides the commands described in the net introduction,
+there are a number of network-internal commands and
+statistics files.
+.SH
+Maintaining the Network
+.IP 1.
+Check the network:
+.RS
+.IP a)
+See if the network daemons are running with the command
+.DS
+% ps ax | grep net
+.DE
+If not running, see below.
+.IP b)
+Check the network queue to see how long commands have been waiting to
+be sent.
+.RE
+.IP 2.
+To restart the network daemons, try
+.RS
+.IP a)
+See if they are running, as above.
+.IP b)
+If so, there should be two net daemon processes per machine connection\(em
+``kill \-9'' the child named ``netdaemon'' and the parent ``netstart'' will start
+a new one.
+.IP c)
+If there are no ``netstart's'' or ``netdaemon's'', executing the shell script
+.DS
+% /usr/net/bin/start
+.DE
+will truncate the log files and start up all the daemons on your machine.
+.IP d)
+To have two ``netdaemons'' pointing to the same machine is to invite disaster.
+What happens is that a few small requests get through,
+and then the error rate goes up by a factor of a hundred.
+The first thing to do when you see this is to check the
+number of net daemons.
+.LP
+(All this must be done as super-user).
+.RE
+.IP 3.
+There are files /usr/spool/berknet/plogfile? with a log for each
+directly-connected machine.
+Example:
+.DS
+% tail /usr/spool/berknet/plogfiley
+.DE
+will tell you in a cryptic form what the network
+has done on the Cory machine.
+This is a good file to inspect to see if transmissions
+are failing, etc.
+.IP
+Basically, ``sends'' begin ``^S'' and end ``^T''.
+If a send fails for some reason, ``^F'' is printed instead of ``^T''.
+``^R'' is printed when a receive begins.
+``RCV'' is entered when the command is received and executed.
+``^P'' indicates a pass through.
+.IP
+The file /usr/spool/berknet/netstat?, one per directly-connected machine,
+have various statistics about the usage of the network, and
+the system load.
+.IP 4.
+The overloading on various machines is causing high error rates.
+If these rates persist, the network can overload to the point
+where the queues are immense and nothing gets through.
+The only thing that can be done at this point is to remove the files (using
+.I netrm
+as super-user) and adjust the delay times in the `initfile'.
+.IP 5.
+If free space is a scarce commodity, truncate logfile and plogfile?,
+and check /usr/spool/berknet/send? and /usr/spool/berknet/rcv.
+If there are any files there which are quite old,
+use your judgement to remove them.
+.IP 6.
+Net news should be provided periodically
+(usually in `/usr/help' or `/usr/news').
+.IP 7.
+The network queues may have too many entries and ``break''
+the simple rendezvous protocol I use. The easiest way to fix this
+is to rename the send directory that is too large, make a new, empty
+one, and move a small group of files in at a time from the rename'd
+directory to the new one. In this way the daemon thinks the sending
+directory is small and it less likely to have problems.
+.IP 8.
+The netdaemons take a number of command line options:
+.DS
+netdaemon \-m mach [\-d] [\-or] [\-os] [\-ou num]
+.DE
+where \-m is required and specifies the remote machine.
+If \-d is set, debug mode is turned on.
+If \-or is specified, the daemon will only recieve, not send, requests
+(``or'' stands for only receive).
+Likewise, \-os is ``only send''.
+Finally, ``\-ou num'', where num is a user-id, as returned by getuid(),
+will force the daemon to only send queue files owned by ``root''
+(pass-throughs), owned by ``network'' (mail, e.g.) and by user-id num.
+.SH
+Setting up the Network
+.IP 1.
+Hardware
+.RS
+.PP
+For another machine to join the network, there must be some hardware link,
+such as tty lines, special character-oriented
+hardware, or DMA lines between the two machines.
+The software does not require the link to be reliable or fast.
+The best way to start is with slow-speed TTY lines
+(say 1200 baud) which demonstrate the network's usefulness at low cost.
+The highest transfer speed on a TTY link is about
+one-half the link speed (at best),
+because of processing time, the 3 \(-> 4 character
+expansion from 8 bits to 6, and the responses.
+.RE
+.IP 2.
+Software
+.RS
+.PP
+To run the network code, you must have a
+.UX
+running Version 6 or 7.
+Version 7 machines should have all the right software already.
+Version 6 systems must have the
+.I make
+command, the ``Version 7'' C compiler that came out a few years
+after initial Version 6 (about 1978), and the
+.I alarm()
+system call.
+This compiler, for example, supports multi-level include files.
+.PP
+There is a directory ``/usr/src/cmd/berknet''
+with all the network source files and a ``makefile''.
+The file ``READ_ME'' has information about
+the different conditional compilation
+option available, and table entries which must be made in the `.c' files.
+.PP
+Assuming the options have been specified in the makefile, the command
+.DS
+% make all
+.DE
+will make all the necessary files.
+Then the command
+.DS
+% make install DESTDIR=
+.DE
+will install the user commands and service programs.
+The directories are specified as options in the makefile.
+Finally,
+.DS
+% make clean
+.DE
+removes all the `.o' and executable files.
+.PP
+There are also other little-used programs, made by ``make othernet''.
+Included are programs to send and receive packets and files, and a program
+to simulate TTY lines using pipes.
+It should not be necessary to run these.
+.PP
+The documentation is in /usr/man/man1 and in /usr/doc/berknet.
+.RE
+.IP 3.
+Directories and Files.
+.RS
+.PP
+The central directories are `/usr/net', which has subdirectories `bin'
+and `network', and `/usr/spool/berknet', which has subdirectories `rcv'
+and `send?', where
+the `?' represents the one-letter codes of the directly-connected machines.
+For various reasons, the support programs
+.I
+(netdaemon, netstart, mmail, mwrite,
+.R
+etc.) must be in `/usr/net/bin'.
+The user programs may be anywhere but the pathnames in ``Paths.h''
+must be reset correctly.
+.PP
+The logfiles are `logfile' and `plogfile?',
+one for each directly-connected machine.
+If not present in `/usr/spool/berknet', they are not created.
+.PP
+The file `/usr/net/bin/start' should start up all the net daemons
+on the current machine.
+This file is normally executed by `/etc/rc'.
+The file `/usr/net/initfile' has a format similar to `.netrc'
+but is read by the net daemons when they are started.
+It has the network device names, speed and various tuning parameters.
+The complete list is in the source file `netrc.c'.
+It is generally possible to change almost anything about the network
+through the `initfile' and restarting the daemon.
+.PP
+The program `/usr/net/bin/netstart' is a simple program to
+start up a net daemon, and if it should abort for any reason, restart it.
+.PP
+There must be an account `network', which executes
+all responses and the free commands.
+Its login directory should be `/usr/net/network' and
+login shell should be `nsh' in that directory.
+The list of free commands can be changed in `nsh.c'.
+.PP
+At Berkeley, we follow the convention that the TTY
+special files are named `/dev/net-X', where `X'
+is the remote machine name.
+.PP
+The
+.UX
+mail program should be modified to recognize
+remote names and to fork a ``/usr/net/bin/sendberkmail'' command.
+Since many people will not or cannot add the options the network
+would like mail to have, there is a program ``v6mail.c'' that
+implements all the options the network wants.
+.RE
+.IP 4.
+Adding a new machine.
+.RS
+.PP
+Tables in `config.h' must be updated.
+Machine descriptions (V6, etc.) must be added to `mach.h'.
+Path names must be specified in `Paths.h'.
+Free commands must be checked in `nsh.c'.
+A procedure ``gothru'' in `sub.c' must be updated.
+All the files etc. described in #3 above must be present.
+.RE
+
+.SH
+Future Plans
+.PP
+It is important to understand the scope of this network;
+what it is and what it is not.
+Since it is ``batched'', there are a lot of things it cannot do.
+Our experience is that remote file copying, mailing and printing between
+.UX
+machines are adequate for our immediate needs.
+.PP
+In the future, we will concentrate on improving
+the hardware and speeding up the network, rather than major user-interface
+changes.
+.PP
+This is a list of the things that have been planned for the future
+for the network.
+.IP 1.
+Use Bill Joy's retrofit library to simulate the version 7 system calls.
+This would reduce the dependence on conditional compilation for V6 code.
+.IP 2.
+The file length restriction is a major inconvenience.
+One way to allow large files would be to
+send large files (over 100,000 chars) only when there are no smaller ones.
+This would be non-preemptive, but might be workable.
+Another way would be to have two hardware links,
+and two sets of daemons, one for large files and one for small ones.
+.IP 3.
+Bob Fabry has suggested generalizing the machine name to
+be user-definable as a login/machine pair, to
+make it easier for people with multiple accounts on multiple machines.
+.IP 4.
+It is possible to share binaries between all
+the similar machine configurations (e.g. the Comp. Center machines).
+This involves ``patching'' the local machine in the binary.
+.IP 5.
+Ed Gould suggested that the notion of ``default'' machine
+was too restrictive\(em
+that an appropriate default for, say, ``netlpr'' was a
+nearby machine with a quality printer, whereas the default for ``net''
+should be the logical most useful machine.
+.IP 6.
+Security \(em
+I have just recently bullet-proofed the network
+so `root' commands are very restricted.
+However, the presence of passwords in the `.netrc' files
+poses a hazard to other machines when one machine is broken into.
+As long as the root password is not in a file, the root is safe.
+I am fairly convinced there is no way using encryption
+to handle the `.netrc' files.
+The introductory documentation is very explicit about
+the threat these passwords pose.
+.IP 7.
+Certain other more exotic requests are unlikely
+to get done until things change:
+.RS
+.IP a)
+Having the same user-id's across machines.
+.IP b)
+Adding an option to ``net'' to wait until a response has been received.
+.IP c)
+There should be a net status command which would
+give things like load averages, the number of users, etc.
+.IP d)
+The notion of a local queue is not general enough\(em
+.I netq
+should print out relevant queues on other machines.
+.IP e)
+Files on intermediate machines can't be \fInetrm\fP'ed.
+.RE
+.SH
+For Berkeley
+.IP 1.
+A driver for the network links to avoid character
+processing would make 9600-baud practical.
+On the Computer Center machines, this could be accomplished
+using a high speed link through the Bussiplexor.
+.IP 2.
+We need a
+.I netrcs
+command to use the rcs facilities from remote machines.
+.SH
+Bugs
+.IP 1.
+Extra files beginning with `df...' are created in the `send?'
+directories, with no control files (`cf...').
+They should be removed periodically.
+.I netrm
+will remove them.
+.IP 2.
+In general, some requests can block the queue until removed.
+Shorter requests will get through, and longer ones will not.
+Again, their net queue files should be removed.
+.IP 3.
+The network rendezvous protocol seems to occasionally get
+in a state where a specific file is continually retransmitted
+and never seems to get through.
+This happens when both the
+host system and the network queues are overloaded, and thus
+is very unpleasant to debug.
+.IP 4.
+The network daemons occasionally core dump.
+They should not.
projects / unix-history / commitdiff