PDP-10.its/doc/syshst/-this-.-too-

This file describes the state things were in around December 1985.
Since then I have moved the host compilation process for ITS to XX
(ie, XX now compiles tables and installs them on the ITS machines as
well as on XX itself).  The ITS flavors of the various TECO macros,
XFILEs, etc, are preserved in AI: SYSHST; AR2 HSTSRC.  They need to be
kept around as a backup in case XX is down for long periods of time.

If you want to figre out what is going on these days, browse through
AI: SYSHST; and XX: HOSTS;.

--sra 17 June 86
----------------------------------------------------------------

[Bugs in MAKHST, MAKDOM, or this documentation to SRA@XX]

This file describes the new host table format (or "extended extended
RFC810 format").  This is the format used to store the host/domain
data for all MIT machines (or that is the intent anyway).  The format
is an extension of the format used by the HOSTS3 compiler ("extended
RFC810 format").  The basic motivation for all this cruft is to keep
all the host data in a single set of files, in spite of the fact that
this data is used in entirely different ways by the Chaosnet and the
Internet.  If you want to flame about the religious issues involved
here, send mail to NAMECALLERS@MC, a list of people who are
collectively responsible for implementing this crock.

== Format:

The only real change is the addition of a new entry type, DOMAIN.
This is still somewhat freeform; I am open to suggestions as to
improvements.  The DOMAIN entry contains three kinds of information,
all related to the domain system (but read on, this matters to
Chaosnet people too).  These are: (1) the name of the domain (loading
origin if this is fed into a nameserver), (2) the data for the SOA RR,
and a list of nameservers (with optional addresses) for this domain.
  The format is:

DOMAIN : <domain-name> : <class> : <source>: <bug-address> : 
 	 <serial> : <refresh> : <retry> : <expire> : <minimum> :
 	 <nameserver> {<address>} {,<nameserver> {<address>}} :
 
(where all of this is on a single line, of course).  Of these, only
the <domain-name> field is currently of any consequence to Chaosnet
hosts or to hosts that keep their SOA and NS data in a seperate file.
Thus the brief form looks like

DOMAIN : EECS.MIT.EDU :

This will work if fed to the MAKHST program, which doesn't care about
SOAs or NSs.  It will *not* work if fed to MAKDOM.  People maintaining
domain nameservers presumably understand what these fields mean (see
RFC883 if you aren't sure).  An example of the complex form (again,
suppressing the line break):

DOMAIN : LCS.MIT.EDU : IN : XX.LCS.MIT.EDU : BUG-LCS-DOMAIN.XX.LCS.MIT.EDU
       : 0 : 7200 : 600 : 3600000 : 60 : XX.LCS.MIT.EDU 10.0.0.44,
         MILO.LCS.MIT.EDU :  

Things to note:

The <address> fields may be blank if the machines acting as
nameservers are all in this domain (and thus have their addresses
listed elsewhere in this file).  If there is an address it is the
entire rest of the subfield (up to the delimiting comma or colon);
this allows for future expansion for Chaosnet nameservers if these
prove to be useful.

The <serial> field may be zero; in this case the <serial> value in the
SOA record is the version number of the source file containing this
DOMAIN entry.  Obviously this only makes sense when the master copy of
the file is kept on a machine that implements version numbers.

The existing filter programs assume that the DOMAIN entry, if it
exists at all, will come before any HOST, GATEWAY, or NET entries.
This could be fixed if anybody gives me a good reason.

One other note: the redundant nicknames for machines have been
removed.  Ie, where there used to be an entry listing names
"MIT-XX.ARPA, MIT-XX, XX", there will now be an entry that only lists
"XX".  The filters can cons up this kind of trivial name easily, and
it turned out to be a lot easier to add the "MIT-"s and ".ARPA"s in
the right places than to remove them from the wrong ones.

== Programs:

There are currently two filter programs, MAKDOM and MAKHST.  Both
could use improvement if anybody is so inclined.


MAKDOM:

This is a C program which will run on Twenex or Berkeley Unix.  Since
these are currently the only operating systems likely to be running
domain nameservers (as opposed to resolvers), this seemed like a
reasonable choice.  It converts this host table format into the form
specified in RFC883 for zone master files.  It behaves like a vanilla
unix filter program, so you can pipe to it, etc, if you have some
reason to do so.  Documentation at this point is just a long comment
at the begining.  There are various switches to control what kind of
RRs are written and to control how many forms of generated nicknames
to add, etc.  Ask me (sra@xx) if you want a copy.


MAKHST:

This is a filter to convert the new host table format into something
that can be fed to the HOSTS3 compiler (or used directly by any
machine that has been using MC: SYSNET; HSTMIT >).  It is implemented
as (gasp) a dumped TECO program.  It has a semi-reasonable command
scanner which will parse a JCL that looks similar to most old ITS or
BOTTOMS-10 programs (if you run it without any JCL it will type out an
error message explaining the argument format).  Since HOSTS3 only runs
on PDP10s and the host tables all currently live on AI (with copies on
XX), the fact that TECO only runs on PDP10s should not be much of a
restriction.  There are (or will be) XFILEs and .CTL files to do the
right frobs to run this filter and feed the results to HOSTS3.  Like
MAKDOM, MAKHST has various switches that let you control nickname
hacking, DOMAIN entry parsing, etc.

There is a third filter program, HSTNIC.  This is also written in
TECO.  It is a little different from the others in that it is not
concerned with the new host table format.  Rather, it does two things.
Firstly, it removes all references to MIT from HSTNIC, since all MIT
hosts should now be in our own tables, quite possibly with different
names than the NIC has on file.  Secondly, HSTNIC punts any machine
names in the HSTNIC file that would conflict with MIT nicknames.  Eg,
UW-EDDIE's nickname of EDDIE gets punted because that conflicts with
the MIT machine in building 38.  The current implementation of this is
extremely kludgy and takes much longer than it should.  I will fix it
some day if I get around to it....

== Files:

HSTMIT has been split up into a number of files, one per domain within
MIT and a few extras for groups within MIT that will probably become
domains soon.  The reason for the split is that the source files will
probably not all live on the same machine any more.  (There have to be
copies on whatever machine is putting together HOSTS3 files, but these
will probably be secondary copies that are kept current via FTP.)  The
ITS names should be obvious, things like HSTLCS >, HSTAI >, etc, and
the conventions on XX are a direct mapping of the MC filenames.
Doesn't really matter so long as responsible people tell whoever is
generating HOSTS3 files where everything is and what it is called.

The NET entries for MIT will be moved into a seperate file of their
own, MC: SYSHST; HSTNET > or something like that.  To avoid name
collisions, The HOSTS3 compilation will also be using a hacked up
version of HSTNIC > with all the MIT entries removed (this is one of
the reasons why the MIT NET entries go in a seperate file).  Again,
all this will be done by some hairy XFILE or .CTL file and shouldn't
need human attention unless it breaks.  But it will be somewhat
compute bound.....

That should be basicly it.  Updates will of course be posted to
INFO-HOSTS@MC.