perm filename INFO.TXT[HST,NET] blob sn#768181 filedate 1984-09-06 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002				     Host Table Information
C00004 00003				    Tables and Table Formats
C00007 00004				    Update Procedure at SAIL
C00012 00005				    Update Procedure at S1-A
C00014 00006				       Files on [HST,NET]
C00016 00007				       Other useful files
C00017 ENDMK
CāŠ—;
			     Host Table Information

Host tables are used to translate between host names (text strings supplied by
the users of network programs) and host numbers required by the operating
system.  The directory [HST,NET] contains most of the files pertaining to host
tables.

As of June 1983, we use an internal form of host tables known as HOSTS3.  This
is a PDP-10-based representation designed especially for Internet host names and
numbers, corresponding to the format outlined in RFC 810.  HOSTS3 format also
handles PUP host numbers on Stanford's local Ethernet.

Host tables change from time to time, and they must be kept up-to-date.  At
SAIL, this is done by checking for a new version of the Network Information
Center (NIC) host table once a day, and retrieving it if it has changed; also
checking for a new version of the PUP network directory.  The PUP network
directory is converted from its binary form to a text file in RFC810 form.  It
and the NIC table are then merged into the HOSTS3-format binary table.

The eventual plan is to replace the use of the host table by queries to network
name servers.  This was supposed to become operative beginning in the spring of
1984, but the schedule has already slipped by several months.
			    Tables and Table Formats

The specification of the text form of host tables can be found in RFC 810,
available as the file <NETINFO>RFC810.TXT at SRI-NIC.  (If a local copy is kept,
it should be stored as RFC810.TXT[RFC,NET].)  It is not too important that this
syntax be understood, because the HOSTS3 program takes care of the details.  The
latest copy of the NIC host table is stored as <NETINFO>HOSTS.TXT at SRI-NIC,
but it is retrieved using the Hostname Server rather than with FTP.  It is
stored as HOSTS.TXT[HST,NET] at SAIL.

A description of the binary format of the PUP Network Directory can be found in
the file <Pup>PupDirectory.press on the IFS.  The directory is stored in binary
form on several hosts; the master copy should be at Navajo in the file
/usr/local/Pup-Network.Directory.  It is retrieved using the PUP Network
Directory Update protocol, and stored as PUPNET.DIR[HST,NET] at SAIL.

Sometimes we retrieve the text source used to generate this directory, although
it is not read by any programs on SAIL.  It is stored as PUPNET.TXT[HST,NET].

The file PUPHST.TXT[HST,NET] contains a locally-generated text form of the PUP
Network Directory, in RFC810 format to allow merging with HOSTS.TXT[HST,NET].
An Ethernet host number such as 50#302# is shown in the file as SU 50#302.

Finally, HOSTS3.BIN[HST,NET] is the binary host table read by most network
programs.  Its format is described in comments in the files HOSTS3.MID[HST,NET],
NETWRK.MID[S,NET] and NETWRK.FAI[S,NET].

There is also a text file, TTYLOC.TXT[HST,NET], giving TTY locations for
Ethertip ports and other local Ethernet hosts.  This is maintained at Score.
There is no binary form; programs that read the file (currently only CHTSER,
using the TTYSTR routine in the NETWRK package) interpret the text.
			    Update Procedure at SAIL

At present, the update procedure is semi-automatic.  It will eventually require
no intervention unless unexpected errors are encountered.

At 3:00 a.m. each day, [HST,NET] runs a batch job (BAT0), which runs the
program UPDATE[HST,NET].  Currently this program does the following things.

1. Queries the NIC Hostname Server to find out the version of its HOSTS.TXT.
   (This is returned as a string.  If you want to do it manually, the
   easiest way is to Telnet to port 101 (decimal) at SRI-NIC, and type the
   command "VERSION".)

2. Reads the version string corresponding to SAIL's current HOSTS.TXT.	This
   string is stored in HOSTS.VER[HST,NET].

3. If they are different, retrieves a new HOSTS.TXT from the Hostname Server
   (using the "ALL" command).

4. Reads the version of our current PUP Network Directory, which is stored
   in the header part of the file (PUPNET.DIR[HST,NET]).

5. Broadcasts this version number in a PUP packet, which will elicit responses
   from any hosts who have a higher version number.

6. Requests a new directory from any host that claims to have a higher number.
   This is stored in PUPNET.DIR[HST,NET], and also converted to text form and
   stored as PUPHST.TXT[HST,NET].

If either the NIC host table or the PUP Network Directory was updated, UPDATE
then sends a message to BUG-HOST (currently, this forwards to JJW).

By examining BAT0.LOG, you can see which of the tables was updated.  To actually
see what has changed, you have to compare the new files with saved versions of
the old files.  This is currently done manually using SRCCOM; eventually UPDATE
may do this automatically.  If the changes are trivial, you may not want to
bother making a new HOSTS3.BIN.

To merge HOSTS.TXT and PUPHST.TXT and write a new binary host table, type

	.al hst,net
	.do merge

This will install a new HOSTS3.BIN, if all goes well.  You may get a "duplicate
host name" message for the host MORDOR, since S1-C has this as a nickname, and
there is a different Mordor in the PUP table.  This error isn't serious, as long
as no one wants to get to the Stanford Mordor.

The TTY location file is not automatically updated.  To get a new version of it,
give the command

	.ftp ttyloc.txt[hst,net]ā†{score}<finger>ttyloc.cmd

It may be useful to SRCCOM the old and new versions to detect changes.

To update the text version of the PUP Network Directory (which is kept here as
PUPNET.TXT[HST,NET] for unofficial purposes only), retrieve it (in Ascii mode)
from one of the following places:
;
; Stored on:	[Navajo]/usr/local/Pup-Network.tx	/* MASTER COPY */
;		[Lassen]<System>Pup-Network.txt
;		[SCORE]SYSTEM:PUP-NETWORK.TXT
;		[Shasta]/usr/local/Pup-Network.tx
;		[Diablo]/usr/local/Pup-Network.tx
;		[Whitney]/usr/local/Pup-Network.tx
;		[SUMEX]SYSTEM:PUP-NETWORK.TXT
;		[SUMEX-2020]SYSTEM:PUP-NETWORK.TXT
			    Update Procedure at S1-A

S1-A's update procedure is actually more automatic than SAIL's.  It runs a
version of the UPDATE program at 3:00 every morning, that checks for a new host
table at SRI-NIC, and it there is one, uses FTP (running on a PTY subjob) to
retrieve a new copy of HOSTS3.BIN from SRI-NIC.

This avoids having to run the HOSTS3 program at S1-A, but it depends on SRI-NIC
keeping their HOSTS3.BIN current with respect to their HOSTS.TXT.  So far, they
seem to be doing so.

S1-A thus has no access to names in the Stanford PUP network directory (except
for hosts also in the NIC host table), but it has no real need for these.
			       Files on [HST,NET]

BAT0.DMP	The nightly batch job
BAT0.LOG	Batch job output log
DO.DO		Various DO command segments
HOSTS.TXT	Latest version of the NIC host table
HOSTS.VER	Version string corresponding to HOSTS.TXT
HOSTS3.BIN	HOSTS3-format binary host table
HOSTS3.DMP	Program to produce HOSTS3.BIN
HOSTS3.MID	Source for HOSTS3.DMP
MERGE.TXT	Input for HOSTS3 program to merge NIC and PUP tables
PUPHST.TXT	RFC810 form of PUP Network Directory
PUPNET.DIR	Latest version of PUP Network Directory
PUPNET.TXT	Text source of PUP Network Directory
TTYLOC.TXT	TTY locations, for FINGER
UPDATE.CTL	Commands for nightly batch job
UPDATE.DMP	Program to retrieve host tables
UPDATE.FAI	Source for UPDATE.DMP
			       Other useful files

NETWRK.FAI[S,NET]	FAIL version of the NETWRK I/O package
NETWRK.MID[S,NET]	MIDAS version of the NETWRK I/O package

Most of the programs on [S,NET] read the host table.  Other programs that do are

MAIL.FAI[MAI,SYS]
NXP[SPL,SYS]		(to find Boise's address)
PRESS.FAI[CSP,SYS]	(to find the Dover's address)
PUPTIM.FAI[CSP,SYS]
WHERE.FAI[CSP,SYS]
WHO[CSP,SYS]

(Please add to the above list any other programs that you know of.)
āˆ‚06-Sep-84  1355	ME  	host table updating 
To:   JJW@SU-AI.ARPA, "#INFO.TXT[HST,NET]"@SU-AI.ARPA
I'm about to leave for three weeks, so I thought I'd tell you what I've
been doing when host table update notices come in.

I have two DO segments on HST,NET that do the SRCCOMs for the NIC and PUP
host tables.  DO HOSTS is for the NIC and DO PUPHST is for PUP.  When I
get a notification from your UPDATE program, I alias to HST,NET, look at
BAT0.LOG to see which host table(s) changed, and then DO HOSTS and/or DO
PUPHST.  Those DO segments want for the (last 3 digits of) the new and old
host table versions.  A copy is made of the new version and then a SRCCOM
is made of that copy with the copy previously made of the old version.
The result file of the SRCCOM is mailed to a file on HST,NET and then
deleted, and you are left with your line editor holding a command to edit
the .MSG file at the right place where the new stuff is.

This way, a record of changes is maintained, for each of the two host
tables.

After you've scanned the changes, you can DO MERGE to make the new binary
file and then delete the copy of the old host table version.  The latter I
do by saying DR .3*<cr> and then delete the old versions with DIRED.  Of
course, this only works because both version numbers are currently in the
300s.

It would be nice if you could automate some of this in the UPDATE batch
sequence (better, in UPDATE itself), with the final result of running
UPDATE being the SRCCOM differences being mailed to the .MSG file(s).
Actually, at this point, I wouldn't mind if the new host table were put up
automatically at SAIL, as long as the SRCCOMs are available for perusal
later, should any problem crop up.  Thanks.