








                     KA9Q NOS


                   USER MANUAL

                     for the

                  KA9Q CWRU/BIOC

             Network Operating System









                                      August, 1994




CONTENTS

1.  INTRODUCTION

2.  ACKNOWLEDGEMENTS

3.  AVAILABLE LITERATURE

4.  ADDITIONAL SOFTWARE SOFTWARE5

5. RELEASE NOTES For CWRU/BIOC NOS
        5.1 Release Notes for CWRU/BIOC Nos
        5.2 Future Developments of CWRU/BIOC Nos

6. HARDWARE REQUIREMENTS

7. INSTALLATION
        7.1  The NOS DIRECTORY STRUCTURE
        7.2  The CONFIG.SYS FILE

        7.3  The AUTOEXEC.BAT FILE
                 7.3.1 A Standard Autoexec File
                 7.3.2  Backing Up the .LOG File
        7.4  The NOS.BAT FILE
        7.5  The AUTOEXEC.NOS FILE
        7.6  The CONFIG.KBD FILE
        7.7  OTHER FILES
                 7.7.1  The POPUSERS File
                 7.7.2  The ALIAS File
                 7.7.3  The FTPUSERS File
                 7.7.4  FINGER Files
                 7.7.5  The \NOS\SPOOL\REWRITE File
                 7.7.6  The MAILKILL File
                 7.7.7  SEARCH RESTRICTION Files
                 7.7.8  The .LOG Files
                 7.7.9  The .DBF Files
                 7.7.10 FTP Files
                 7.7.11 The FILTER File
        7.8  RUNNING KA9Q UNDER WINDOWS
                 7.8.1  Preamble
                 7.8.2  Running KA9Q Under Windows
                 7.8.3  The EDOS Program
        7.9  SLIP CONNECTIONS
                 7.9.1  SLIPLOG
                 7.9.2  SuperTCP
        7.10  REMOTE RESET of the SERVER
        7.11  REMOTE MANAGEMENT of the SERVER
        7.12  MEMORY HINTS
                 7.12.1 General Settings
                 7.12.2 Memory Requirements and Garbage Collection
        7.13  SETTINGS For PC/TCP CLIENTS

8. POP2, POP3 and SMTP INFORMATION
        8.1  SETTING UP For POPMAIL
        8.2  POP2/POP3
        8.3  SMTP

9. The GOPHER SERVERS
        9.1  SETTING UP
                 9.1.1  The Gopher Server
                 9.1.2  The Gopher2 Server
        9.2  GINFO FILES
                 9.2.1  Gopher Types
                 9.2.2  Ginfo File Structure
                 9.2.3  A Simple Ginfo File
                 9.2.4  Downloading PC Binaries and Mac Binhex Files
                 9.2.5  Links to Other Gophers and Telnet Links
                 9.2.6  A Wombat Example
                 9.2.7  Special Note on Ginfo Files
                 9.2.8  FTP Connections
                 9.2.9  Accessing WWW HTML Files
        9.3  Type 7, SEARCH ITEMS
                 9.3.1  Text File Searches
                 9.3.2  Menu File Searches
                 9.3.3  DBF File Searches
                 9.3.4  Tips on Search Exclusions
                 9.3.5  Setting Up a Gopher Subject Tree
                 9.3.6  Other Search Examples
        9.4  AUTO-INDEX GENERATION
                 9.4.1  The mkginfo() Function
                 9.4.2  Gopher Types in mkginfo()
                 9.4.3  The MENU.CAT File
                 9.4.4  An Auto-Generated Index Example

10. The CSO SERVERS

11. The TIME SERVER

12. PACKET FILTERING
        12.1  INTRODUCTION and SUMMARY
        12.2  DETAILED INFORMATION

13. The WWW SERVER
        13.1  INTRODUCTION
        13.2  INSTALLATION
        13.3  SOME WWW TERMS
        13.4  HTML FILES
        13.5  IN-LINE IMAGES
        13.6  WWW CONNECTION TYPES
        13.7  LEARNING HTML
        13.8  HTML EXAMPLES
                 13.8.1  The CWRU WWW ROOT.HTM
                 13.8.2  The WOMBAT ROOT.HTM
                 13.8.3  The WOMBAT GEOLSITE.HTM

14. The FTP SERVER
        14.1  INTRODUCTION
        14.2  The FTPUSERS File
        14.3  Other FTP Files
        14.4  Setting Up An Anonymous FTP Server

15.  NOS SECURITY
        15.1  General Considerations
        15.2  Preventing Anonymous Access to the Telnet Server
        15.3  Setting Up a Public Message Area


16. NOS TESTING

17. OTHER APPLICATIONS For KA9Q NOS
        17.1  KA9Q as a Mail Router with News
        17.2  KA9Q as a TCP/IP Router for Novell Servers
        17.3  JNOS as a BootP Server
        17.4  The NOSCJ Version




1.  INTRODUCTION


KA9Q NOS11 is a fully fledged Network Operating System (NOS) which
runs under DOS. As a Network Operating System it is capable of
performing the following functions:

               Mail Server         - POP2/POP3/SMTP
               FTP Server          - ftp, anonymous ftp, telnet   
                                     and finger
               CSO Name Server     - actually 3 search engines and 
                                     2 CSO servers
               NTP Server          - a time server
               Gopher Server       - a very stable gopher server, 
                                     there are actually 2 gopher  
                                     severs
               WWW Server          - http world wide web server

The KA9Q NOS was originally written by Phil Karn. The KA9Q Gopher
code was written by Chris McNeil, with later enhancements by Chris
and Peter Crawshaw. David Mishler added IP Filtering which has
increased the security of the NOS and permits IP based restrictions
of menu items in the Gopher Server. Ashok Aiyar added some local
enhancements as well as the WWW Server code, resulting in the
NOS11C-A version.

While we do not believe that the code will damage your computer, if
it does, there is not much we can do about it.  We will share your
anguish but not your financial loss.

Copyright:
NET/NOS (KA9Q) is copyright Phil Karn (karn@chicago.qualcomm.com).
You can use the executable for free if you are at an educational
site or are a ham, otherwise, you owe Phil money.

This manual is copyright by Phillip Ingram and Mark Johnson.
Unless, of course, we used someone elses work or ideas, then the
copyright is theirs. We have tried to give credit where it is due,
and ask that you do the same. You may feel free to use, copy or
distribute all or part of this document provided this copyright
notice goes with it.

Disclaimer:
This manual is a compilation from various sources and people. It is
the manual for NOS11C-A.EXE, the current version of KA9Q NOS. We
hope it is both useful and helpful. If, following our instructions
causes you pain and suffering, sorry, but there is nothing we can
do about it. There is something you can do. Tell us what went wrong
so we can make the changes and help out the next person.


2.  ACKNOWLEDGMENTS

The following people contributed greatly to the development of the
KA9Q NOS for it to reach its current state. Many thanks to these
people:

          Phil Karn           <karn@chicago.qualcomm.com>
          Chris McNeil        <cmcneil@mta.ca>
          Peter Crawshaw      <pcrawshaw@mta.ca>
          David Mischler      <mischler@cubic.com>
          Ashok Aiyar         <ashok@biochemistry.cwru.edu>
          Steven Klepzig      <sklepzi@ssb1.saff.utah.edu>
          Jacob deGopler      <jrd5@po.cwru.edu>
          Farhad Anklesaria   <fxa@boombox.micro.umn.edu>
          Kai Getrost         <kai@pyrite.som.cwru.edu>
          Jon Lewis           <jlewis@inorganic5.chem.ufl.edu>


This manual is a collection of material from previous manuals,
email messages to the ka9q mailing list and other material. The
people responsible for the manual are:

          Ashok Aiyar         <ashok@biochemistry.cwru.edu>
          Phillip Ingram      <pingram@laurel.ocs.mq.edu.au>
          Mark Johnson        <mark@cases.pubaf.washington.edu>
          Jon Lewis           <jlewis@inorganic5.chem.ufl.edu>

Other people who unknowingly contributed to the manual include:

          Robert Clift        <cufabc@sfu.ca>
          Karl-Heinz Weiss    <khweiss@mvmhp.ciw.uni-karlsruhe.de>


Mark Johnson also maintains a searchable online manual of the KA9Q
NOS documentation. This also has links to many software locations
mentioned.



3.  AVAILABLE LITERATURE


Potential users of KA9Q should be, or make themselves, familiar with the
following information available on the net:

i) The email LISTSERV for KA9Q users:

Ashok Aiyar maintains a MAJORDOMO e-mail listserv for KA9Q users. This
listserv is available for discussions about configuration, installation,
suggestions and implementation regarding the KA9Q NOS.

Topics for discussion on the mailing list could include:

     - General KA9Q configuration.
     - FTP, SMTP, POP3 server configuration
     - Gopher/WWW/CSO server configuration, tips, tricks etc
     - The use of software associated with gopher or WWW and not
          necessarily pertaining to KA9Q NOS.

a) The list name had to be smaller than 9 characters, and the CWRU campus
MAJORDOMO administrator approved the following address:

     <pcgopher@po.cwru.edu>

To post a message to the list, send mail to <pcgopher@po.cwru.edu>

b) The version of MAJORDOMO is quite selective, and will reject email
from people not subscribed to this list. If you consistently cannot post
to the list, you may wish to re-subscribe to the list AND send Ashok e-
mail, so he can unsubscribe the incorrect address.

c) Subscription to the list: Send mail to <majordomo@po.cwru.edu>. There
should be no subject, and the text should be exactly the following:

     subscribe pcgopher <your_email_address>
     end
   
     OR

     subscribe pcgopher
     end
   
(in the second case, MAJORDOMO will grab an e-mail address out of your
message headers)

d) To unsubscribe from the list: Send mail to <majordomo@po.cwru.edu>.
There should be no subject, and the text should be exactly the following:

     unsubscribe pcgopher <your_email_address>
     end

     OR

     unsubscribe pcgopher
     end
   
(in the second case, MAJORDOMO will grab an e-mail address out of your
message headers)

e) To receive information about the list: Send mail to
<majordomo@po.cwru.edu>. There should be no subject, and the text should
be exactly the following:

     info pcgopher
     end

f) To see who else is subscribed to the list: Send mail to
<majordomo@po.cwru.edu>. There should be no subject, and the text should
be exactly the following:

     who pcgopher   
     end

g) To receive more help with MAJORDOMO:

Send mail to <majordomo@po.cwru.edu>. There should be no subject, and the
text should be exactly the following:

     help
     end

h) The command "end" at the end of the message will ensure that MAJORDOMO
does not try to find commands in your signature file.

ii) A detailed manual can be downloaded using the following bookmark:

     host:          cases.pubaf.washington.edu
     port:          70
     type:          1
     path:          1c:/manual
     URL:      gopher://cases.pubaf.washington.edu/11c:/manual

Copies of the manual in various formats, including ASCII, Word Perfect
5.1, Word for Windows, and postscript. Also located here is an online
searchable gopher text manual plus links to selected software. This
service is maintained by Mark Johnson <mark@cases.pubaf.washington.edu>.


iii)  The following usenet news groups:

               comp.infosystems.gopher
               comp.infosystems.www.misc
               comp.infosystems.wais


iv) The ph (CSO Name Server) FAQ:

This is maintained by Noel Hunter <noel@wfu.edu>. The faq is posted to
comp.infosystems.gopher. It may also be obtained by anonymous ftp or by
Gopher.  Ftp to ftp.wve.edu and look in /pbu/usenet/ph-FAQ.  To retrieve
the FAQ via Gopher point your Gopher at gopher.wfu.edu on port 70 in
/Wake Forest Information/Computer Information/Usenet News Information
maintained by Wake...


v) The Gopher FAQ:

This faq is posted to comp.infosystems.gopher. It may be obtained by
anonymous ftp from rtfm.mit.edu:/pub/usenet/news.answers/gopher-faq, or
by gopher to 129.130.10.5, path=0/Frequently Asked Questions
(FAQs)/gopher-faq, port=70


vi) The WWW FAQ:

This faq is posted to comp.infosystems.gopher and comp.infosystems.www.
It can be obtained by anonymous ftp from rtfm.mit.edu in
/pub/usenet/news.answers/www/faq. The faq is maintained by Thomas Boutell
<boutell@netcom.com>.


vii) The WAIS FAQ:

This faq is posted to comp.infosystems.wais and comp.infosystems.gopher.

viii) An introduction to the HTML language is available from:

          http://www.ncsa.uiuc.edu/demoweb/html-primer.html
          http://info.cern.ch/hypertext/www/Technical.html
          http://theme.music.indiana.edu/www.doc/desc.html
          ftp://ds.internic.net/rfc/rfc1630.txt
          http://info.cern.ch/hypertext/WWW/Addressing/Addressing.html

ix) The comp.protocols.tcp-ip.ibmpc FAQ:
Bernard Aboba's comp.protocols.tcp-ip.ibmpc FAQ has lots of configuration
tips for SLIP connection.

x) Documentation and utilities for the conversion of IBM (ASCII) to ISO
8859 are located at the following bookmark (you need to be bilingual in
French and English):

host:     biochemistry.bioc.cwru.edu
port:     70
type:     1
path:     1c:/pub/nos/utils/uqamutil
URL: gopher://biochemistry.bioc.cwru.edu:70/11c:/pub/nos/utils/uqamutil

xi) Documentation on The Internet Gopher Protocol can be found at the
following locations:

Name=protocol.txt
Type=0+
Port=70
Path=0/gopher/gopher_protocol/protocol.txt
Host=boombox.micro.umn.edu
<URL=gopher://boombox.micro.umn.edu/00%2Fgopher%2Fgopher%5Fprotocol%2F
protocol%2Etxt%09%2BText%2Fplain%20En%5FUS>

Name=DRAFT_Gopher_FYI_RFC.txt
Type=0+
Port=70
Path=0/gopher/gopher_protocol/DRAFT_Gopher_FYI_RFC.txt
Host=boombox.micro.umn.edu
<URL=gopher://boombox.micro.umn.edu/00%2Fgopher%2Fgopher%5Fprotocol%2F
DRAFT%
5FGopher%5FFYI%5FRFC%2Etxt%09%2BText%2Fplain%20En%5FUS>

xii) nos_1229.txt, the documentation of the original NOS which contains
a detailed description of the basic functions of all NOS versions. It is
somewhat out of date and doesn't cover some of the things in nos11c. It
can be found at inorganic5.chem.ufl.edu in /gopher/pub/nos.

xiii) Slip.txt by Jon Lewis is a 'how to' file for setting up a nos based
slip server, but it includes basic information on autoexec.nos commands
with examples of autoexec.bat, config.sys, k9q.bat, slip.nos, noslip.nos
and some comments. It is available from inorganic5.chem.ufl.edu in
/nos/slip.txt.





4.  ADDITIONAL SOFTWARE SOURCES


The most recent version of the KA9Q Gopher server can be downloaded via
Gopher using the following bookmark:

     host:     biochemistry.bioc.cwru.edu
     port:     70
     type:     1
     path:     1c:/pub/nos
     URL: gopher://biochemistry.bioc.cwru.edu/11c:/pub/nos

In addition to the nos executable, some of the following software may be
necessary to run or configure KA9Q, its servers or its files, data or
images.

The most recent version of NOS11CJ can be downloaded via gopher from the
following bookmark:

     host:     inorganic5.chem.ufl.edu
     port:     70
     type:     1
     path:     1c:/nos
     URL: gopher://inorganic5.chem.ufl.edu/11c:/nos


i) Ethernet Packet Drivers: The latest Crynwr (& old Clarkson) packet
drivers are available from many sites, but try the following bookmark at
Oakland:

     host:     gopher.acs.oak.oakland.edu
     port:     70
     type:     1
     path:     ftp:oak.oakland.edu@/pub/msdos/pktdrv/
     URL: gopher://gopher.acs.oak.oakland.edu:70/1ftp:oak.oakland.edu@
          /pub/msdos/pktdrvr/

or anonymous ftp to oak.oakland.edu and look in pub/msdos/pktdrvr.

ii) POPMail client: If you are using winsock for LWP, then Eudora for
Windows is recommended. Anonymous ftp to ftp.qualcomm.com

If using DOS take a look at: 
     - Nupop at ftp.acns.nwu,
     - Minuet or Popmail/PC from boombox.micro.umn.edu.

These DOS ones support packet drivers and some TCP stacks like PCTCP from
FTP Software.

iii) Use PaintShop Pro for Windows for the manipulation of images in one
of the following formats: GIF, TIFF, BMP, PCK, RLE, JPG, JIF. It is
available from: ftp.cica.indiana.edu in /pub/pc/win3/desktop.

iv) For the ability to detect and play nearly any sound file through a
Windows 3.1 Waveout device, use wplany.exe. wplny09b.zip is available
from ftp.cica.indiana.edu in /pub/pc/win3. If you do not have a waveout
device then you can use speak.exe, a Windows speaker driver available by
anonymous ftp from ftp.microsoft.com.

v) SLIPlog by Karl Weiss is a small TSR that expands any SLIP
packetdriver with login and remote control features which are needed if
you want to assemble a secure, reliable and cheap SLIP Gate with
ka9q/nos. Some information on SLIPLog can be found in Section 7.9, and
copies of it is available via gopher on Mark's server at the following
bookmark:

     Name=SLIPLOG Distribution
     Type=1
     Port=70
     Path=1c:/public/sliplog
     Host=cases.pubaf.washington.edu
     URL=gopher://cases.pubaf.washington.edu/11%3A%2Fpublic%2sliplog

It is also available Ashok's biochemistry gopher server.

vi) MAKESRCH by Steven R. Klepzig creates a summary of the Gopher
directory and saves this summary in a GINFO file. Use this bookmark to
download MAKESRCH:

     Selector: Makesrch GINFO file builder (MAKESRCH.ZIP, 1389 bytes)
     Type:          5
     Port:          70
     Path:          9c:/pub/nos/utils/makesrch.zip
     Host:          biochemistry.bioc.cwru.edu

Or you can anonymous FTP to ssb1.saff.utah.edu and look in
pub/gopher/server/ka9q.

vii) GEdit by Steven R. Klepzig is a simple gopher menu file editor. It
reads in an existing file, creates new files, displays the contents in
a scrolling list box, popping up a dialog box upon <INS> or <ENTER> to
edit an existing item and handles the placing of <TABS> in the output
file when saving it.

     Selector: GEdit Ginfo File Editor (g4edit.zip)
     Type:          5
     Port:          70
     Path:          9c:/pub/nos/utils/g4edit.zip
     Host:          biochemistry.bioc.cwru.edu

viii) Tiny Editor (Ted3) is a small ASCII editor that saves <tabs> as
<tabs> and not spaces. These tabs are crucial for the GINFO files of
Gopher. This is available from biochemistry.bioc.cwru.edu.

ix) A Microsoft Windows HTML editor that seems to have a lot of features
is HTML Writer. The zip file with all the documentation can be found at
lal.cs.byu.edu in /pub/www/htmlwrit.zip.

Other HTML editors include HTML Edit, available from ftp.cica.indiana.edu
and for the file htmledit.zip. Another html editor for windows is
htmlasst. It is available by anonymous ftp from ftp.cs.dal.ca in
/htmlasst/htmlasst.zip. The program requires vbrun300.dll which is in
vbrun300.zip.

There are other html editors, and Word Perfect to html converters. All
are mentioned in the www newsgroup.

x) The GET utility is used to capture the date in a .bat file. It can be
used in the autoexec.bat to facilitate automatic archiving of log files
(refer section 7.3.2). It is available in the archive /pub/nos/get24.zip
from biochemistry.bioc.cwru.edu.

xi) PKZip is a standard file compression utility. It can be used in
conjunction with the GET utility to archive the .log files (refer section
7.3.2). It is available as a self extracting archive from many archive
sites as pkz204g.exe, including biochemistry.bioc.cwru.edu in pub/dos.

xii) EDOS v3.65d enhances Dos in Windows in 386 enhanced mode and provide
you with much more memory. Available from winftp.cica.indiana.edu in
pub/pc/win3/util/edos365.zip. It is a shareware program, $69 for
registration.

xiii) PKTMUX by Graham Robinson. This can been used to multiplex packet
drivers to allow the use of multiple TCP/IP stacks. It is available as
pktmux12.exe from biochemistry.bioc.cwru.edu.

xiv) CSAP.EXE by Don Williams can sort into ascending or descending order
the contents of Dos directories for use by the mkginfo() function. It is
available from biochemistry.bioc.cwru.edu.




5. RELEASE NOTES For CWRU/BIOC KA9Q NOS


5.1  The CWRU/BIOC KA9Q NOS

The current version of the CWRU/BIOC KA9Q NOS is called NOS11C-A.EXE. The
following are the release notes taken directly from Ashok's release notes
for version 1.92, and paraphrasing several other sources.

Release notes for CWRU/BIOC NOS:

The version of NOS used is CWRU/BIOC nos11c-a. The base source c code for
these versions of KA9Q are N1BEE 0.85-beta, which in turn is based on
PAOGRI.EXE which are described below:

nos11c-a (June, 1994)
- Fix a bug in the SMTP which affected people who use a VMS mail host.
- Some ftp server changes, including:
a) Each directory can have a message file that is automatically sent to
the connecting FTP client.
b) There is a new command, "ftpmaxclient", which will limit on the number
of concurrent FTP clients that can connect to the NOS FTP server.
- The command "ip filter <interface> list" now has proper formatting, and
works with screen flowcontrol as well as with a remote sysop login.

nos11c (May, 1994)
Modifications to the mkginfo() function so that in addition to generating
an index for all files and subdirectories "on the fly", a previously
generated index file called "menu.cat" can optionally be sent to the
client.

nos11a (January, 1994)
HTTPd (World Wide Web Server) added to KA9Q. It runs on TCP port 80. The
HTTP protocol requirements were guessed at after seeing the messages sent
by WinMosaic to the WWW server www.ncsa.uiuc.edu, and making the
fundamental assumption that HTML retrieval is very similar to Gopher
document retrieval. Inline gifs are retrieved using gopher.

nos10b (December, 1993)
- CSO servers added, listening on ports 70, 105 and 150, from code by
Chris Mcneil and Peter Crawshaw.
- Daytime server added (TCP only), listening on port 13.
- DOS 6.0 compatibility added.
- FTP client supports "help", "pager on|off" and "view <remote-file>".
- AT command added which permits timed command execution.
- BOOTP support has been disabled (was added in v1.85).
- Three search engines added to the Gopher server.
- A second gopher (gofer2) server added, listening at port 150.
- FTP server can display file ftp.txt as a pre-login greeting.
- FTP inactivity timeout added, uses the command "ftpdisc <secs>".
- IP packet filtering (from David Mischler) added.
- NTP Client/Server (written by Giles Todd and Mark Turner) added.
- After three unsuccessful login attempts to the Mailbox, the session is
disconnected.
- Detailed log of all gopher transactions added in gopher.log. This file
can be automatically mailed to the    server administrator with the
command "sendgopherlog name@host" command.


v1.92 (another build, April, 1993) It was realised that LZW compression
during SMTP send/receive transactions is not standard SMTP protocol, and
there was no reason why it should be included at all, especially as these
versions of NOS cannot be used over radio. The software was recompiled,
removing LZW support. Since nothing in the code has been changed, the
version number remains the same.

v1.92 (April, 1993)
After much trial and error, the POP2 server was working with the
University of Minnesota POPmail/PC and POPMail/Mac clients.  Many thanks
to Chris McNeil (cmcneil@mta.ca) for his help, and also Kai Getrost
(kai@pyrite.som.cwru.edu) for sending his modified FINGERD.C for G1EMM
NOS that gave a couple ideas.

v1.91 (March, 1993)
Chris McNeil's Gopher server for Ka9Q added.  A big thank-you to Farhad
Anklesaria (fxa@boombox.micro.umn.edu) and also to Chris McNeil for very
graciously providing the code and helping to get it compiled okay.
Without his help and assistance, this version would not be possible.

v1.86
BOOTP fixed as described by Steven Johnson to correctly recognise a 32-
bit IP address.

v1.85
BOOTP and BOOTPD support added.  BOOTP is not supported in Pa0GRI 2.0m
and N1BEE 921225v0.85s-beta distribution releases.

v1.8
a) Optimised for POP3/SMTP function.  During compiling extraneous servers
like ax25, pop2, nntp etc. were left undefined.

b) Support for only the packet driver interface.  Other interfaces such
as ASY, KISS, PI, EAGLE, SCC etc. were also left undefined.

c) The base code for this version is from N1BEE v0.85s-beta, which has
a fully functional POP3 server, unlike other versions of NOS such as WG7J
1.07b where POP3 function is broken.

d) The code for the SMTP server is from WG7J 1.07b since that version
includes the "smtp t4" command, which is very useful (see later)

e) The SMTPSERV.C has been modified as described by Jacob DeGlopper
(jrd5@po.cwru.edu) to bounce incoming mail that is directed at non-
existent users.  Previous versions of KA9Q do not have this feature.

f) This version was compiled for 286 and higher computers.

g) We find that it is very stable as a mail-server

h) This version (and configuration files provided below) are to be used
with POP3 clients such as POPmail/PC and POPmail/Mac.  It is not expected
that any users will want to actually telnet into the NOS mailbox and
check their mail.



5.2  Future Developments of CWRU/BIOC NOS

According to Ashok, Phil Karn will be releasing a protected mode version
of NOS sometime in 1995. It is Ashok's intention to move the gopher
servers to Phil's latest code, as well as some of the other changes
(ftpcli, smtpcli, smtpserv, pop3serv).

The protected mode version will make so much more memory available to do
a lot of things that are not possible within the limits imposed by DOS
conventional memory.



6. HARDWARE REQUIREMENTS


This version of NOS requires at least a '386 computer to run. The
recommended minimum requirement is a '386 SX machine with 2 Mb RAM. The
performance of the NOS greatly improves with the use of a Disk Cache,
such as SMARTDrive 4.0 from Windows 3.1 (512-1024 Kb disk cache
recommended).

The machine running the 'wombat' gopher is a '386 20 MHz computer with
2 Mb RAM and a 300 Mb ESDI hard disk. Ashok's server is a 40 Mhz '386
computer with 4 Mb RAM and 175 Mb hard disk.

If you are not using a SLIP connection then you require an ethernet
network card with an ip number and packet driver loaded, and a connection
to the Internet via a Unix host.

Before you start, you need to obtain the following information, usually
from your network administrator:

     - the packet driver software interrupt (from 0x60 to 0x7f)
     - your IP address
     - your hostname
     - your domain suffix
     - your subnetwork mask, and broadcast address
     - the IP address of your gateway (router)
     - the IP address(es) of your domain nameserver(s) (optional)
     - the IP address/hostname of an SMTP smarthost (optional)

For Ashok's gopher server, these values are:

     packet driver loaded on software interrupt 0x60
     ip address: 129.22.152.44
     hostname: biochemistry.bioc.cwru.edu
     domain suffix: cwru.edu. (note the trailing period)
     subnetwork mask: 255.255.0.0 (he is using a Class B network)
     broadcast IP address: 129.22.255.255
     gateway (router): 129.22.1.1
     primary DNS: 129.22.4.1
     secondary DNS: 129.22.4.3
     SMTP smarthost: po.cwru.edu (129.22.4.2)

For the wombat gopher server at the Macquarie University site these
values are:

     packet driver loaded on software interrupt 0x69
     IP Address: 137.111.94.83
     host name: wombat.es.mq.edu.au
     domain suffix: es.mq.edu.au.
     Subnet Mask: 255.255.0.0 (we are on a Class B network)
     Broadcast ip address: 137.111.255.255
     gateway (router): 137.111.1.11
     Primary Domain Name Server: 137.111.1.11
     Secondary Domain Name Server: 137.111.1.12
     SMTP Server: 137.111.1.11

One problem that keeps reappearing in the KA9Q mailing list has its
source in an incorrect value for the subnet mask. It is advisable to
check with your network administrator for the appropriate subnet class
your machine will be on.




7. INSTALLATION


7.1  The NOS DIRECTORY STRUCTURE

In this example, the default root drive is taken to be C:\. This may
be varied according to your situation eg. a Novell Netware drive,
another Dos partition on your hard disk etc.

From the root directory, create the following subdirectories:

     - \NOS              holds the AUTOEXEC.NOS, ALIAS,
                         POPUSERS, FTPUSERS, FINGER and CONFIG.KBD
                         files.

     - \NOS\SPOOL        holds the various log files (*.LOG) for
                         logging NOS activity and the rewrite file
                         which contains the rules by which outgoing
                         mail is rewritten.
     - \NOS\SPOOL\HELP   (optional) holds the help file.
     - \NOS\SPOOL\MAIL   mail messages are held here.
     - \NOS\SPOOL\MQUEUE for outgoing mail work files.
     - \NOS\SPOOL\RQUEUE not used
     - \NOS\SPOOL\TEMP   temporary files get created here

     - \GOPHER           files for the gopher server go in this
                         directory and its subdirectories.
     - \GOPHER\WEBGIF    store graphics .gif image files for
                         use by the www server.
     - \GOPHER\PUB       files available for anonymous ftp go in
                         this directory and subdirectories under
                         it.


     - \GOFER2           files and subdirectories for the gopher2
                         server.

     - \WWW              htm files for the www server go in this
                         directory and its subdirectories.



7.2  The CONFIG.SYS FILE

It is likely the KA9Q server will be a dedicated stand-alone
machine. KA9Q cannot use EMS/XMS memory. It can however use as
much conventional memory as you can provide. Using DOS 5.0, it
is possible to provide as much as 736 Kb of conventional memory
of which 714 Kb is free for use. More memory is obtainable with
Dos 6.n. This is highly recommended for normal KA9Q use. To do
this, the computer must not have a monochrome video adaptor
(MDA). A suggested config.sys file is as follows:

--- begin ---
        device=c:\dos\himem.sys
        device=c:\dos\emm386.exe i=a000-b7ff i=e000-f7ff noems
        rem NOTE: you may need to exclude the memory location used
        by
        rem       your network card, so modify the above line
        accordingly.
        device= c:\dos\ansi.sys
        dos=high
        files=100
        buffers=50
        fcbs=4,0
        stacks=9,128
        shell=c:\command.com c:\ /p /e:1200
--- end ---

The range A000-B7FF can be included as conventional memory if:

        - you do not use VGA graphics (KA9Q doesn't)

        - you do not have a monochrome display adaptor (MDA).


If you are running KA9Q under Windows, then a CONFIG.SYS similar
to the following may be appropriate (NB: it uses the QEMM memory
manager, so you need to add SystemROMBreakPoint=false to the
system.ini file)

--- begin ---
        device=c:\qemm\qemm386.sys ram x=a000-afff x=b000-cfff
        fr=e000 rom=f000-ffff
        device=c:\qemm\loadhi.sys /r:1 c:\dos\ansi.sys
        dos=high
        files=50
        buffers=30
        shell=c:\command.com c:\ /p /e:1200
        stacks=9,256
--- end ---

Refer to section 7.8 running KA9Q under Windows for more
information.


7.3  The AUTOEXEC.BAT FILE

7.3.1 A Standard Autoexec File

The calling sequence upon system startup is:

          autoexec.bat -> nos.bat -> nos executable

The nos executable uses autoexec.nos, config.kbd and optionally the
filter configuration files.

An example of a typical autoexec.bat file is as follows:

--- begin ---
     @ECHO OFF
     path c:\;c:\dos;c:\telnet;c:\nos;c:\gopher c:\dos\doskey
     c:\dos\share
     PROMPT $p$g
     rem SET the CITY and MESSAGE string variables and the TZ variable
     rem for the time sever.
     set CITY=Macquarie University, Sydney, Australia
     rem set MESSAGE=whatever text you want
     set TZ=est-10gmt
     rem load the packet driver
     c:\8003pkdr /b:240 /r:cc00 /i:10 /e:69
     rem run the nos.bat file
     c:\nos
     exit
--- end ---


7.3.2  Backing Up the .LOG Files

It is possible to get the system to back up the .LOG files weekly,
monthly or whatever time frame you require. This example uses GET and
PKZIP, refer to section 4 additional software resources for information
on where to obtain these programs. The GET utility is used to capture the
date and use the date in renaming the log files. PKZIP is used to
compress the archived logs. The relevant portion of the sample
autoexec.bat file is given below.

In this example NOS is set to reboot the computer at 12:30 midnight. The
log files are  archived into a zip file only if the hour is midnight,
otherwise NOS is executed via a batch file.  For this to work, keep the
GET syntax exactly as is shown:

--- begin ---
     get h 16
     if %get% == 0 goto backup
     goto exit

     :backup
     set get=
     get H 4
     set M=%get%
     set get=
     get H 2
     set D=%get%
     set get=
     get HE 8
     set Y=%get%
     set get=
     cd \logs
     target *.zip -b60 -n -v -ho
     pkzip c:\logs\%M%-%D%-%Y%.zip c:\nos\spool\*.log
     del c:\nos\spool\*.log

     :exit
     c:\nos.bat
--- end ---

You also need two lines at the end of your autoexec.nos file which will
unlock the keyboard and reboot the computer. These lines use the "at"
command and are similar to:

--- begin ---
     at 0029 "mypassword"     # unlock the keyboard
     at 0030 "remote -k mypassword my_hostname reset"  # reboot
--- end ---

The "at" command works as if you were typing text at the keyboard. It
also works in sysop mode. In both cases the keyboard needs to be unlocked
first.

Be warned that this method will not work under Windows as there is a
conflict in re-booting the machine by this method and Windows.



7.4  The NOS.BAT FILE

It is important that the tmp variable be set to \nos\spool\temp and
that the NOS executable be called as is shown from the \nos
subdirectory.

--- begin ---
     @echo off
     set tmp=c:\nos\spool\temp
     cd\nos
     rem a loop can also be placed here rather than in the
     autoexec.bat file
     rem now call the NOS executable
     nos11c-a -d/nos -s50 autoexec.nos
     cd c:\
--- end ---


7.5  The AUTOEXEC.NOS FILE

Autoexec.nos is the configuration for the nos and starts the various
servers. It can be configured in one of 2 ways, using bootp or not
using bootp. The first example given is from Ashok's server and uses
the bootp method. The second example does not use the bootp method.

Before you start, you need to know:

     - the packet driver software interrupt (from 0x60 to 0x7f)
     - your IP address
     - your hostname
     - your domain suffix
     - your subnetwork mask, and broadcast address
     - the IP address of your gateway (router)
     - the IP address(es) of your domain nameserver(es) (optional)
     - the IP address/hostname of an SMTP smarthost (optional)


A) Example 1: Bootp

# Sample autoexec.nos for nos11c-a.exe
#
# for biochemistry.bioc.cwru.edu, written by Ashok Aiyar
# <ashok@biochemistry.cwru.edu>
#
#
# For my gopher server, the appropriate values are:
#
# packet driver loaded on software interrupt 0x60
# ip address: 129.22.152.44
# hostname: biochemistry.bioc.cwru.edu
# domain suffix: cwru.edu. (note the trailing period)
# subnetwork mask: 255.255.0.0 (we are a Class B network)
# broadcast IP address: 129.22.255.255
# gateway (router): 129.22.1.1
# primary DNS: 129.22.4.1
# secondary DNS: 129.22.4.3
# SMTP smarthost: po.cwru.edu (129.22.4.2)
#
# these values are provided to help you understand the
# configuration file below.  Do NOT use the same values
# in your autoexec.nos.  Check with your network administrator
# for the appropriate values at your site.
#
# Lines beginning with "#" are not read by NOS.
#
# memory parameters
memory efficient yes
memory ibufsize 1152             # ibufsize should be greater than
MTU
memory nibufs 5
watch on
watchdog on
memory thresh 8192
#
# basic host configuration
ip address 129.22.152.44
hostname biochemistry.bioc.cwru.edu
domain suffix cwru.edu.
#
# attach & configure packet driver interface
# MTU is set at 576 bytes
attach packet 0x60 pk0 10 576
ifconfig pk0 ipaddress 129.22.152.44
ifconfig pk0 netmask 255.255.0.0 broadcast 129.22.255.255
#
# Setup routes (these WILL be different for your configuration!)
route add default pk0 129.22.1.1
route add 129.22.0.0/16 pk0
#
# domain nameserver (DNS) configuration 
domain addserver 129.22.4.3
domain addserver 129.22.4.1
domain verbose off
domain translate off            # never turn on - causes serious
memory leak
domain cache size 20
domain cache wait 300
domain cache clean yes          # discard expired DNS records
domain retry 1
domain maxwait 30
domain diskbuf 1024
#
# TCP/IP parameters
ip rtimer 60
ip ttl 255
tcp mss 536                     # mss = mtu - 40
tcp window 2144                 # window = 4 times the MSS
tcp irtt 3000
tcp syndata off                 # don't turn on, it breaks some TCPs
#
# NOS mailbox - unattended operation
mbox attend off
mbox secure on
mbox maxmsg 50
mbox expert off
mbox password "mypassword"      # password used during remote sysop
operation
third-party off
#
# let's maintain a log!
log \nos\spool\net.log
#
# telnet client accept echo request from remote server
echo accept
#
# NTP client
time server 129.22.4.3          # use the NTP server on your net
time set                        # set the PC clock
#
# SMTP parameters
smtp batch no                   # batching commands confuses some
clients
smtp gateway po.cwru.edu        # insert the name of your SMTP
smarthost
smtp maxclients 4
smtp mode route
smtp quiet yes                  # don't beep when mail is received
smtp timer 60                   # check for ourgoing mail every
minute
smtp t4 120                     # after 2 minutes of trying, use the
smarthost
smtp usemx yes                  # use MX records during DNS lookup
#
# remote reset/exit/kick parameters
start remote                    # to permit remote kick/exit/restart
remote -s "mypassword"          # password used to authenticate
remote command
# remote system usage would be:
# remote -k "mypassword" biochemistry.bioc.cwru.edu kick|reset|exit
#
# FTP parameters
ftype image             # FTP server default protocol binary
ftptdisc 300            # 5 minutes of inactivity causes a reset
ftpmaxcli 5             # upto 5 FTP clients can connect
simultaenously
#
# The following servers are available:
# CSO listener TCP port 105
# daytime listener TCP port 13
# discard listener TCP port 9
# echo listener TCP port 7
# finger listener TCP port 79
# ftp listener TCP port 21
# gopher listener TCP port 70
# gopher listener TCP port 150
# pop2 listener TCP port 109
# pop3 listener TCP port 110
# remote listener (default UDP port 1024)
# smtp listener TCP port 25
# telnet/mailbox listener TCP port 23
# time listener TCP port 37
# http listener TCP port 80
# 
# start the servers (start only those that you need)
# NOTE that any lines that "start" a server cannot have any
arguments
# on the same line besides "start server", comments are not allowed
# start cso
# start daytime
# start discard
# start echo
# start finger
start ftp
start gopher
start gopher2
# start pop2
start pop3
start remote
start smtp
start telnet
start time
start www
#
# configure the keyboard and IP packet filtering
source c:\nos\config.kbd
source c:\nos\filter
#
# define the keyboard password, and lock the keyboard
lock password "mypassword"
lock
#
# at 12:30 a.m. unlock the keyboard, then reboot the computer
at 0029 "mypassword"                            # unlock the
keyboard
at 0030 "remote -k mypassword 127.0.0.1 reset"  # reboot!
#


B) Example 2: Without Bootp

# Lines beginning with "#" are not read by NOS.
#
# memory parameters
memory efficient yes
memory ibufsize 3072
memory nibufs 10
watch on
watchdog on
memory thresh 14336
#
# basic host configuration
attach packet 0x69 pk0 10 960
#ifconfig pk0 broadcast 255.255.255.255  # otherwise bootp won't
work
#bootp pk0
ifconfig pk0 ipaddr 137.111.94.83 netmask 255.255.0.0 broadcast
137.111.255.255
route add default pk0 137.111.1.12
route add 137.111.0.0/16 pk0
hostname wombat.es.mq.edu.au
ip address 137.111.94.83
domain suffix es.mq.edu.
#
# domain nameserver (DNS) configuration 
# DNS server IP will be received by BOOTP
domain addserver 137.111.1.12
domain addserver 137.111.1.11
domain verbose on
domain translate off            # never turn on - causes serious
memory leak
domain cache size 50
domain cache wait 600
domain cache clean yes          # discard expired DNS records
domain retry 1
domain maxwait 30
domain diskbuf 4096
#
# TCP/IP parameters
ip rtimer 60
ip ttl 255
tcp window 4096
tcp mss 960
tcp irtt 10000
#
# NOS mailbox - unattended operation
mbox attend off
mbox secure on
mbox maxmsg 200
mbox expert off
mbox password "<mypassword>"   # password used during remote sysop
operation
third-party off
#
# let's maintain a log!
log \nos\spool\net.log
#
# telnet client accept echo request from remote server
echo accept
#
# NTP client
time server 137.111.1.11          # use the NTP server on your net
time auto on                    # automatically set the PC clock
time delay 120                  #     every 2 hours
time read                       # get current GMT time from the
server
time set                        #     and set the PC clock
#
# SMTP parameters
smtp batch no                   # batching commands confuses some
clients
smtp gateway 137.111.1.11       # insert the name of your SMTP
smarthost
smtp maxclients 40
smtp mode route
smtp quiet yes                  # don't beep when mail is received
smtp timer 60                   # check for ourgoing mail every
minute
smtp t4 120                     # after 2 minutes of trying, use the
smarthost
smtp usemx yes                  # use MX records during DNS lookup
#
# remote reset/exit/kick parameters
start remote                    # to permit remote kick/exit/restart
remote -s "mypassword"         # password used to authenticate
remote command
# remote system usage would be:
# remote -k "mypassword" biochemistry.cwru.edu kick|reset|exit
#
# FTP parameters
ftype image                     # FTP server default protocol binary
ftptdisc 600                    # 10 minutes of inactivity causes a
reset
#
# start the servers
start ftp
start smtp
start pop2
start pop3
start finger
start telnet
start gopher
start time
start gopher2
start cso
start www
#
# configure the keyboard and IP packet filtering
source c:\nos\config.kbd
source c:\nos\filter
#
# define the keyboard password, and lock the keyboard
lock password "mypassword"
lock
 

7.6  The CONFIG.KBD FILE

The config.kbd file should be located in the \nos directory. It is
accessed with the command "source c:\nos\config.kbd" in the
autoexec.nos file. Use the following CONFIG.KBD file:

--- begin ---
     # mapping F1 through F4
     fkey 59 "session 1\n"
     fkey 60 "session 2\n"
     fkey 61 "session 3\n"
     fkey 62 "session 4\n"
     # mapping F5 through F8; F10 is always escape tp console
     fkey 63 "tcp status \n"
     fkey 64 "mem status\n"
     fkey 65 "status\n"
     fkey 66 "smtp list\n"
--- end ---



7.7  OTHER FILES

7.7.1  The POPUSERS File

This resides in C:\NOS directory. It contains the usernames and
passwords of those using popmail and having popmail addresses.
If not using POPMail then there is no need for the file.

                #POP password format
                #user:password:
                phillip:pword1:
                david:pword2:

Every user in the POPUSERS file should have an entry in the
FTPUSERS file described in section 7.7.3 the ftp users file.


7.7.2  The ALIAS File

This file resides in the C:\NOS directory. Mail aliases can be
used to forward mail, or send the same message to a group of
users. Three examples are given below:

Again, this file is optional.

# Example 1: Mail sent to this user gets forwarded to another
address

       alias1               someone@host.domain

# Example 2: Mail sent to this "user" gets forwarded to several
users

       alias2               ashok marty samantha david

# Example 3: Mail sent to this user gets forwarded to another
group of users

       faculty          richard martin jonathon david susan jerry
                         bill joyce


Every alias in the ALIAS file requires an entry in the FTPUSERS
file, as described in section 7.7.3.  You need to create an entry
in FTPUSERS for every alias, but not for every address that the
alias is banged out to.  No entries in POPUSERS are needed for
the alias or the alias recipients.

For example:

Say the mailserver is "biochemistry.cwru.edu", the alias is
"oligo-users", and it is banged out to

a) ashok@biochemistry.cwru.edu
b) zxg@po.cwru.edu
c) user@magnus.acs.ohio-state.edu

The entry in the ALIAS file would look like:

    oligo-users ashok zxg@po.cwru.edu user@magnus.acs.ohio-
    state.edu

The entry in FTPUSERS would look like:

   oligo-users oligo-users /nos/spool/mail/oligo-users.txt /128

The only other entries needed are for "ashok" in FTPUSERS and
POPUSERS.  The entry in FTPUSERS is necessary because he receives
mail on the same system, and in order to retrieve mail, he needs
to have an account in the POPUSERS file. Refer to Section 8.1 for
more information on setting up the files for POP3/SMTP.


7.7.3  The FTPUSERS File

The FTPUSERS file is compulsory if you wish users of the POPMail
clients, POPMail/PC or POPMail/Mac to be able to send mail to
other users within the system. It is also necessary if you wish
to provide ftp access to users, and set up an anonymous ftp site.

A) POPMail Users

i) POP Users

The format of the POP user entries in the FTPUSERS file is shown
below:

    # pop users format
    # user password location-of-mail-file 128
    user1 pword1 /nos/spool/mail/user1.txt 128
    user2 pword2 /nos/spool/mail/user2.txt 128

ii) Alias's

It is imperative that every alias in the ALIAS file have an entry
in the FTPUSERS file. The alias entries have the following
format:

     # alias format
     # alias password location-of-mail-file 128
     alias1 pword3 /nos/spool/mail/alias1.txt 128
     alias2 pword4 /nos/spool/mail/alias2.txt 128


B) FTP Users

It is possible to provide telnet and ftp access to the KA9Q
server with varying levels of protection and rights. The standard
ftp/telnet access passwords format is:

    user    password /directory_access_to protection_level

The protection levels include:

        1        - read access only
        3        - read/write but not delete
        7        - read/write/delete
        127      - remote sysop access
        128      - this user is banned from Telnet access to
                         mailbox

Some examples are:

# Example 1:  anonymous ftp
anonymous * /pub 1
# user=anonymous, any password, read only access to c:\pub
directory and all
# sub-directories below it.

# Example 2:  anonymous ftp - incoming
anonymous * /pub/incoming 3
# user = anonymous, any password, set up an incoming subdirectory
to allow
# users to donate software/data etc

# Example 3:  sysop access
superuser secret / 127
# set superuser sysop rights everywhere, with password = secret

Ashoks FTPUSERS file provides a good example of POP/alias/ftp
configuration.

# [ftp-accounts]
anonymous * /public 1
bioc password /bioc 3
root password /127
# remote sysop access
#
# [mail-accounts]
ashok ashok /nos/spool/mail/ashok.txt 128
marty marty /nos/spool/mail/marty.txt 128
jonathon jonathon /nos/mail/jonathon.txt 128
#
# [aliases]
alias1 alias1 / 128
alias2 alias2 / 128
#
# end FTPUSERS example



7.7.4  FINGER Files

Finger files are optional. They are located in the \NOS\FINGER
directory. There is one file for each user and the file must have
the same name as the USERS name. For example user ASHOK will have
a finger file called ASHOK and it could contain:

Username: ashok                   In Real Life: Ashok Aiyar
Telephone: x3300                  Room: West 409/410

These finger files are plain ASCII text files. They can contain
any information regarding the user that you wish to make
available.


7.7.5  The \NOS\SPOOL\REWRITE File

This is an important file. This file rewrites outgoing mail
addresses as desired. This is particularly useful if you wish to
route mail through a particular SMTP gateway.

Ashok's rewrite file currently looks like:

--- begin ---
        *@*.bitnet $1%$2.BITNET@cunyvm.cuny.edu
        *@*.BITNET $1%$2.BITNET@cunyvm.cuny.edu
        *@biochemistry $1@biochemistry.cwru.edu
        *@meds38956 $1@biochemistry.cwru.edu
        *@meds38956.cwru.edu $1@biochemsitry.cwru.edu
--- end ---


7.7.6  The MAILKILL File

This is located in the \NOS directory. It contains a list of
addresses. Mail from these senders will be rejected. If you do
not wish to receive mail from the user uucp@attmail.com, then the
mailkill file will have the single line:

uucp@attmail.com

All other addresses from attmail.com will work fine, only mail
from uucp@attmail.com will be rejected. MAILKILL should be used
with care.


7.7.7  SEARCH RESTRICTION Files

A)  DBFWORDS.TXT

This file is locate in \NOS directory. It contains a list of
words on which DBF Searches will not be performed.

B)  BADWORDS.TXT

This file is locate in \NOS directory. It contains a list of
words (strings and substrings) on which text file searches will
not be performed.

C) GOPHER.BAD

This file is locate in \NOS directory. It contains a list of
words (strings and substrings) on which Menu File Searches will
not be performed.


7.7.8  The .LOG Files

The NOS logs all activity. These are stored in .LOG files which
are located in the \NOS\SPOOL directory. NET.LOG is a summary of
all activity. GOPHER.LOG is a log of the gopher and CSO activity.
GOPHER2.LOG is a log of gopher2 and the CSO2 database.  MAIL.LOG
is a log of mail activity.  Note that you must insert the line
log /nos/spool/net.log in the autoexec.nos file to record all
network activity in the NET.LOG file.  All other logs are created
automatically.

These files may be automatically archived. This procedure was
described in an earlier section.


7.7.9  The .DBF Files

The CSO Servers are able to search data base files if they are in the
dBase III or dBASE IV format. They must be located in the \NOS directory
where the NOS executable is located. Refer to section 10 for information
regarding the CSO Servers.

One of the file search engines can search DBF files with "p" and "q" type
searches. Refer to section 9.3.3 on DBF File Searches.

Note that you don't need dBase to create a file in the dBase format as
many spreadsheets and other packages are capable of writing to the dBase
format. For example, Quattro Pro or Microsoft Access can be used for the
creation of the .DBF files for CSOn and File searches. Don't forget the
first record is the field names.

Refer to Section 9.3.3 on some reported problems with .DBF files created
with some software.




7.7.10  FTP Files

A) FTP.TXT

The file \NOS\SPOOL\FTP.TXT is an ASCII file that is displayed when
an ftp session is established as a pre-login message (type "220").


B) MESSAGE.FTP

The MESSAGE.FTP files, located in each ftp accessible subdirectory,
is a message file that is automatically sent to the connecting FTP
client. This is a plain text file. The server will prefix every line
with "230- " or "250- " as is appropriate. According to the RFC,
"220" is to be used with a pre-login message, "230" is to be used
with a message associated with a login, and "250" is to be used with
a message associated with the "CWD" command.


7.7.11  The FILTER File

This file is located in the \nos directory. It is accessed with the
command:

     source c:\nos\filter

in the autoexec.nos file.

The file contains the commands for packet filtering. Refer to Section 12
for further information. An example file from Mark Johnson's server is
given below:

-----begin

# Setup Packet Filtering
#
# permit in all TCP packets except TCPSYNs
ip filter pk0 permit in tcpxsyn * *
#
# permit the following computers access to the gopher2 server (150)
#
#
# Access for a range of computers.
#
ip filter pk0 permit in tcpsyn 199.164.217.34/24 128.95.208.79:150
#
# Access for individual computers
#
ip filter pk0 permit in tcpsyn 128.95.208.97/32 128.95.208.79:150
ip filter pk0 permit in tcpsyn 128.95.208.103/32 128.95.208.79:150
ip filter pk0 permit in tcpsyn 128.95.208.105/32 128.95.208.79:150
ip filter pk0 permit in tcpsyn 128.95.208.177/32 128.95.208.79:150
ip filter pk0 permit in tcpsyn 128.103.180.21/32 128.95.208.79:150
ip filter pk0 permit in tcpsyn 128.122.188.181/32 128.95.208.79:150
ip filter pk0 permit in tcpsyn 128.32.252.57/32 128.95.208.79:150
#ip filter pk0 permit in tcpsyn 128.95.55.30/32 128.95.208.79:150
#
#
# More Packet Filtering Setup
#
# Deny ALL other computers access to the gopher2 port (150)
ip filter pk0 deny in tcpsyn * 128.95.208.79:150
# allow all other traffic (smtp, pop2, pop3, remote etc. etc.)
ip filter pk0 permit in * * *
ip filter pk0 permit out * * *

-----end


7.8  RUNNING KA9Q UNDER WINDOWS

The following is from an email message from Robert Clift
<clifta@sfu.ca> on running KA9q under windows:


7.8.1  Preamble

I've attached to the bottom of this message my instructions on
setting up  KA9Q under Windows.  Despite my promise to Ashok, I
have yet to clean up the  document and provide him with a stick
diagram.  It's coming Real Soon Now.

I don't know about DIS_PKT9, so there may be some wrinkles with
that, but  the info below allows KA9Q to work under Windows,
using a standard packet  driver and PKTMUX.  I've never tried
using WINPKT and I don't think it will  work. I believe it is
only for Windows applications and not DOS application  run under
Windows.

>2.   Assuming one can run KA9Q under Windows, can one run two
copies of
>      KA9Q on the same machine then?  Do I need PKTMUX?

You can not run two copies of KA9Q under Windows (at least I
haven't been  able to make it work).  Why do you need to do so? 
There might be a better  way to do what you want.


7.8.2  Running KA9Q Under Windows

Okay, two things to consider when running KA9Q from a DOS box in
Windows.   First, KA9Q must have a packet driver to operate over. 
As I am also running  Winsock, and wanted another packet driver
available just in case, I use  PKTMUX to multiplex the packet
driver.  Here is an excerpt from my AUTOEXEC.BAT:

--- begin ---
c:\network\3c503 -n-d-w 0x60 5 0x300 0xc800
c:\network\pktmux 3/4
c:\network\pktdrv /!l /lt80
c:\network\pktdrv
c:\network\pktdrv
--- end ---

The first line loads the packet driver for my card.  The second
loads PKTMUX  which mulitplexes the packet driver, thus allowing
the use of multiple  TCP/IP stacks.  In this case, PKTMUX is
loaded with room for 3 drivers, but  buffers for 4 drivers (to
improve throughput).

The next line loads a virtual packet driver for Winsock. Now this
is  important, the "/!l" switch tells the Winsock not to listen
for requests  from anybody.  If you don't do this, the Winsock
will intercept all requests  to the KA9Q servers.  The second
switch "/lt80" tells the driver to listen  for requests on TCP
port 80 (and only port 80 due to "/!l"), which is used  by
SERWEB, a winsock compliant WWW server. The next two lines load
virtual  packet drivers, one for KA9Q, and one as a spare.

You can designate which interrupts the packet drivers use, but
I decided to  let the interrupts be allocated automatically, and
used the PKTSTATS program  which comes with PKTMUX to determine
which interrupt was which for the  purposes of setting up the
software.

It is important to note that you must use PKTMUX 1.2d or later. 
Earlier  versions do not work correctly with Winsock.  The PKTMUX
archive contains  PKTMUX, PKTDRV, PKTSTATS and documentation. 
You will have to find a packet  driver for your card on your own. 
I got mine from the Clarkson collection.

After determining which virtual packet driver is allocated to
which  interrupt, configure KA9Q accordingly.

The next step is to start Windows and set up a PIF for KA9Q. Here
are the  important settings from my PIF file:

 -Video Memory: Text
 -Memory:         Required -1               Desired -1
 -Execution: Background

Advanced Setup

 -Background Priority 100                   Foreground Priority 100
 -Detect Idle Time

Memory Options
  
  - Uses High Mem
  - Lock Application Memory

Display
      
  - Emulate Text Mode

Some of these settings were discovered using voodoo debugging,
so they could  be changed.  The most important ones are to lock
the application memory, and  request/desire -1 memory.  By
requesting -1, you are asking for all  available memory, which
KA9Q desperately needs.

This brings me to a side note on memory.  As KA9Q needs all the
conventional  memory it can get its hands on, it is wise on boot
up to load everything you  can into high memory before running
windows.  This way you can maximise the  memory available to KA9Q
(memory fiends may want to experiment with memory  allocation to
squeeze out as much as possible).

You then start KA9Q from the PIF, and assuming everything is set
up right,  you are ready for connections.  Now you may want to
experiment with your  AUTOEXEC.NOS setup in regular DOS before
tyring it in Windows, just to  convince yourself that at least
that part works.

Now a few words about connecting to your server.  I have found
that it is  not possible to connect to the server from a client
operating on the same  machine.  So for instance, you can't use
a gopher client to connect to the  KA9Q server on the same
machine.  What I do to test the system is telnet out  to another
host and use that host to connect to the server. Or, you can 
always use another PC to connect to the server PC.  I haven't
figured out  why this is so, as I can connect a Winsock WWW
client to my Winsock WWW  server, but I have just accepted it as
a limitation.

New Information on PKTMUX

I've conversed with Graham Robinson, the author of PKTMUX, and
he informs me  that PKTMUX cannot deal with a client on one
channel trying to contact a  server on another channel.  It is
a non-trivial problem, and not a priority  for him.

Anyway, it is hardly a full explanation, but it should help you
on your way.   If you have any questions, don't hesitate to drop
me a line.


7.8.3  The EDOS Program

The following is an email posting from Ashok Aiyar:

Just one comment for anyone trying to run KA9Q under Windows. You
really should try a program called EDOS (Enhanced DOS), which
provides very nice settings for running DOS programs under
Windows including up to 736K per DOS box.

Here is a small blurb about it:

EDOS 3.65-D Enhances DOS in Windows 386 mode   Registration  $
69.00 WIN_UTIL AUG93 DOS WINDOWS ENHANCED 386 MEMORY CLIPBOARD
BACKGROUND PIF
STACK EDOS
FILES: EDOS365D.ARJ

Author: Michael Maurice

Enhances DOS in Windows 386 Enhanced Mode. Oversize DOS sessions
to 736k. Change PIF settings from command line. Menu bar in
Windowed session with many tools. Edit/Append. Drag/Drop. Special
Background task support. Exit Windows without closing idle DOS
sessions. Start Windows apps from the command line. View
clipboard from  command line. Change window title. Always on top
feature. Put up Windows Message box from DOS. Switch to Windows
from DOS command line. Dangerous DOS command disabled. Many other
features.  Diagnostics. See articles in Feb. & March 93 Compute
Magazine. Also, InfoWorld June 22,29 1992, Brian Livingston's
column. PC Week  Nov. 4, 1992. "...be aware that EDOS does things
Microsoft doesn't  believe possible", Jerry Pournelle-Byte
Jan,93.  Programmers interface. ALL features enabled. Nag screen
at start-up & 30 minutes. Registration $45/w discount.


Hardware Requirements: IBM  PC, PC-compatible  or MS-DOS 
computer 4meg RAM, hard drive with 1/2meg disk space.

Other Requirements : DOS 3.3 or higher and 386 Enhanced Mode
Windows 3.1.

Please note that I am not associated with the author in the least
bit.  I have used the product and it works.  KA9Q  is really much
better off with as much memory as you can provide  it, and from
that perspective, EDOS is pretty neat.


7.9  SLIP CONNECTIONS

7.9.1  SLIPLOG

This is a description of the SLIPLOG program which is an access-control
program for a slipgate. It is of interest to those who wish to configure
KA9Q as a SLIP server with increased security.

SLIPLOG, and the following description, was written by Karl-Heinz Weiss.


The SLIPLog distribution has been reorganised, slipkit.zip now contains
the complete stuff = sliplog.zip and all other programs (nos,
packetdriver etc). Here comes the last announce:

SLIPLOG is a small (<6K) TSR that expands any SLIP-packet driver with
login and remote control features, which are needed if you want to
assemble a secure, reliable and cheap SLIPGate with ka9q/nos. All you
need is an old PC (286 or better recommended, but 8086 will work), a
cheap Ethernet card, one  or more (up to 4) modems, and of course a LAN
to which you are allowed to connect.  You will need a minimum of 2 IP
addresses assigned to you.  I've added all the programs you'll need to
my SLIPKIT distribution file:  the latest nos-version from Jon Lewis,
Peter Tattam's slipdriver, Graham Robinson's packet multiplexer (v1.2b),
the winpkt packet driver, SLIPLOG, the related utilities COMTOOL and
GETNEWS, a completely rewritten new manual, and some docs (ka9q*.txt,
nos_1229.txt, slip.txt) you should read to understand the ka9q Net
Operating System. SLIPLOG, COMTOOL and GETNEWS are free for
non-commercial use. I've also added the assembler source
code to this distribution.

Some SLIPLOG-Features:

       - Function control of the gate with a real cold boot on error.
       - Sends content of a user defined message file after connect.
       - Sends the SLIP IP address after a user logs in successfully.
       - Authentication of callers, with time and date written to a
       logfile.
       - Programmable, with individual call-back possible.
       - Dial on demand (dial-out) possible.
       - Individual maximum daily online times for each user.
       - Full remote control of the SLIPGate (with sysop password)
       possible.
       - Switching from SLIP-session to remote control at any time.
       - Integrated mini-terminal program (i.e., for dialing).
       - Integrated diagnostic routines.
       - Perfect running in a MS Windows' DOS-window (including remote
       control and reset).
       - Fixes hang-up-problems during the connect phase of the modem.
       - Services more then one line by simply adding another SLIPLOG.

You may obtain SLIPLOG.ZIP (the sliplog stuff only) and SLIPKIT.ZIP (=
SLIPLOG +all other programs) from these sites:

       mvmpc9.ciw.uni-karlsruhe.de                /gopher/public/nos
       biochemistry.cwru.edu                      /gopher/pub/nos
       inorganic5.chem.ufl.edu             /gopher/pub/nos

(these sites are running ka9q/nos as server. If your GUI ftp doesn't know
this server type, try a command line ftp or gopher to port 70).



7.9.2  SuperTCP

The following is a reply by Ashok Aiyar to a question posed to
the KA9Q mailing list.

>
>I would like to add a SLIP connection for my own use.  I want to be able
>to dial in from anywhere and use a gopher client to retrieve info from
>the gopher server.  I do not need access beyond that machine.
>
>Can I slap a modem in the machine and configure a SLIP connection?  Does
>this require a second machine running ka9q?  If either of these work, do
>you have any notes on configuring the SLIP connection?

While setting up a modem is certainly possible, it is perhaps
more prudent to do this on a different machine, using a different
version of KA9Q optimized for SLIP routing.

You will need to be assigned an IP address for your SLIP machine.

I have some configuration files, but you are best off looking at 
Bernard Aboba's comp.protocols.tcp-ip.ibmpc FAQ .... which has
lots of configuration tips.

BTW, the other option that you have (well worth the money) is to
invest in a copy of Frontier Technologies SuperTCP, which is a
WinSock compliant TCP stack that has support for multiple
interfaces and routing -- so it will work perfectly as a SLIP
router on a Windows machine.  Additionally, it is the most
complete Winsock implementation on the market today, and was the
first all DLL implementation.  I recommend it very highly.

Frontier will also be shortly releasing a product which will let
you use WinSOCK software at home by dialling into your machine
at work even if you do not have a SLIP IP address.  I am quite
closely associated with the development of this product, and it
is really impressive.



7.10  REMOTE RESET of the SERVER

The ka9q server can be rebooted remotely. To do this you first need
the following lines in your autoexec.nos

        remote -s "pword"   # replace "pword" with your password
        start remote

Then from any NOS system, type:

        remote -k pword gopher.bus.utah.edu reset (or "exit")

If you can access the NOS console then type:

        remote -k pword 127.0.0.1 reset

where:          reset = reboot
        exit = exit the currently running session on KA9Q

If you use a combination of "at" and "remote" commands you can do
a timed reset. The "at" command works as if you were typing text at
the keyboard. It also works in sysop mode. In both cases the
keyboard needs to be unlocked first.

For example:

        at 0030 "remote -k pword 127.0.0.1 reset"

If you have the keyboard locked, then before using the command
above, you must first unlock the keyboard.  For example

        at 0029 "password"
        at 0030 "remote -k pword 127.0.0.1 reset"

It is recommended to reboot NOS daily with an at-command to free up
memory that KA9Q so desperately needs in its operation.



7.11  REMOTE MANAGEMENT of the SERVER

The following is an excerpt from nos1229.man by Phil Karn. It describes
how Nos manages and prompts for passwords for remote telnet access as
mentioned in the following part.

"When a password is defined (max 30 characters) then (s)he is prompted
with 5 numbers before letting her/him in. The five numbers represent the
5 character locations in the string defined, whereby the first character
is number 0. Multiple lines of 5 characters can be send to fool
"snoopers". The end of password sending is signalled with an empty line.
If there was a good response, sysop mode is entered. The setting of the
password can only been done by the system console or AUTOEXEC.NOS startup
file."

Issuing the 'at' command at the mailbox prompt will put the result in a
series of numbers. These numbers represent the mbox password, which must
be set for this to work,  e.g.

mbox password week

the number sequence might be: 0 2 2 1

This represents characters 0, 2, 2, and 1 of week...weee. So in reply to
0 2 2 1 you would type weee <enter> and you will then be at the net>
prompt.  You can then check on things like mem st, socket, tcp st, but
there are commands you should not use, like dir and ftp.  Play around
with it from a local machine before you start doing alot of remote
maintenance.

If you want full remote control of your system over a modem, you can use
Karl's sliplog.  This lets you do anything you want from the net> prompt,
even exit nos without losing your connection or control of the system.


7.12  MEMORY HINTS

7.12.1  General Settings

KA9Q is memory hungry. There are two aspects to consider, the amount of
memory below 1 Mb which can be made available for NOS, and the settings
in autoexec.nos which affects the way in which KA9Q handles the memory
it has.

If you're running on a 386sx or better (you must be if you use nos11c-a)
and you're running a dedicated system with nos running under Dos (no MS
Windows) you can get quite a bit of memory. Ashok's latest ka9q documents
tell of a way to expand your dos memory using emm386.exe. If you don't
plan to
use graphics or have a MDA text display, you can: 

       device=c:\dos\emm386.exe i=a000-b7ff noems 

This can give you about 735kb total Dos memory. If all drivers are loaded
high into UMB's then when the nos heap grows there still is plenty of
room to spare. Things would have to really go wrong for a server to run
out of memory. The nos heap on the system should not go much above 200kb,
which would now leave over 150kb coreleft.

Net> mem st
heap size 178480, avail 94816 (53%), morecores 312, coreleft 180832
allocs 25929, frees 25718 (diff 211), alloc fails 0, invalid frees 0,
overused 0
garbage collections yellow 0, red 0
interrupts-off calls to malloc 0, free 0
Intqlen 39, Ibufsize 1046, Iminfree 34, Ibuffail 0
 
Jon Lewis' document slip.txt gives some information on the settings for
MTU, MSS, TCP Window and ibufsize as these settings seem to have alot to
do with how nos uses RAM. This document is recommended reading. In it he
says a stable performance should result using MTU=1024, MSS=984, TCP
Window=3936, ibufsize=1046 and nibufs=40.

If the NOS is to act as a router then it may be necessary to set the MTU
to the maximum allowed value, eg MTU=1500, MSS=1460, TCP Window=5840,
ibufsize=1522 and nibufs=35.

Note that this ibufsize doesn't work when the system is a slip server,
but does just fine when it's not a slip server.  Totally different
settings should be used for a slip server.


7.12.2  Memory Requirements and Garbage Collection 

KA9Q/NOS is memory hungry in its operation, and generally requires
>150 Kb of coreleft. As stated below, free memory will tend to
decrease over the day. Rebooting Nos, either manually or with an
at-command, will free up memory. Morecore errors in the net.log
file can result from the garbage-collection process, as descibed
below by Carl-Heinz Weiss in response to a query on memory errors
reported in the net.log file.

> This is a problem that I've had off and on in the past, and it
usually
> goes away by itself. I occasionally get several pages of errors
in
> the net.log file that look something like:
> 
> Sun Jul 24 22:25:40 1994- morecore: Failure requesting 31201
(coreleft 26241)
> Memory ststus: heap size 203952, avail 111168 (5%) morecores 1251
coreleft 2624
> Allocs 635139, frees 634046 (diff 1093), alloc fails 1041,
invalid frees 0,
> overused 0
> Garbage collections yellow 0, red 0
> Efficient 1, Threshold 7168
> Interrupts off calls to malloc 0 free 0

Indeed we have this problem with all versions of ka9q/nos. As I
understand the sources, garbage-collection is a process triggered
every second. When memory goes low, the garbage-collector tries to
free memory and this fails for some obscure reason. In my
experience, the frequency of such errors depends on some settings
in your autoexec.nos, the speed of your computer and the protocols
routed over your machine. After a long period of trial and error,
I found this paramters working best for me: (It's a 386/40,
configured as a single line sl/ethernet-gate)

        # Memory
        memory thresh 15000
        memory efficient yes
        memory ibufsize 1600
        memory nibufs 30

        # TCP/IP
        tcp mss 1460
        tcp window 6000
        tcp irtt 5000

        # Interface
        attach packet 0x62 sl0 5 1500
        attach packet 0x61 en0 5 1500 

It's very important, to have enough memory, at least 150kB
immediately  after booting  nos. Free memory decreases over the
day, but after some times it should remain stable at a certain low
level > 50kB. This depends on the traffic and the sort of protocols
handled by nos. A very critical sort of traffcic is the routing of
a telnet-session over slip, if the incoming client is using a large
packetsize (mtu > 296). If this client starts an irc-session, then
doing a /help or /list -command, memory goes low immediately, and
after this, the garbage-collection fails and nos will crash or stop
all activities. (A note: you could reduce the mtu-size in the
attach-statement for the slip to 296.  But not all clients behave
well with this setting).

With the settings outlined above, I had my gate on and running for
more then 5 days without rebooting. However it's a good idea, to
reboot nos with an at-comand once a day, so the memory bug  should
never become a problem.



7.13  SETTINGS FOR PC/TCP CLIENTS

If you experience problems with with FTP Inc's PCTCP FTP DOS client
crashing a KA9Q Server try setting the follwing parameters.

If you are on ethernet, set the memory interrupt buffer size to be
1500 bytes. "mem ibufsize 1500"

>attach packet 0x60 pk0 10 552

>tcp mss 512




8. POP2, POP3 and SMTP INFORMATION


8.1  SETTING UP For POPMAIL

Here are the things that must be done to get KA9Q pop3/smtp
working.

a) Create the following directories:

        (rootdir)\spool
        (rootdir)\spool\mail
        (rootdir)\spool\mqueue

b) Create the following files:

        (rootdir)popusers
        (rootdir)ftpusers

(rootdir) = directory that AUTOEXEC.NOS resides in.  This is
usually C:\NOS, so rootdir is \nos.

Every user-name that must RECEIVE mail on the KA9Q system must
have an entry in FTPUSERS.

Every user that can RETRIEVE mail from the KA9Q system must have
an entry in POPUSERS.

Sample FTPUSERS entry:
        ashok bogus-password some-path #

Typically, entries read like this:
        ashok bogus-password /nos/spool/mail/ashok.txt 128

Sample POPUSERS entry:

        ashok:mypassword:

c) If you want to define aliases, create the following additional
file (rootdir)alias
The format of this file is:

        alias           user1 user2 user3
eg:     ka9q-gopher     user@host1 user@host2 etc. etc.

Remember for the alias ka9q-gopher to receive mail on the NOS
system, a corresponding entry for "ka9q-gopher" must be placed
in FTPUSERS.

d) Start SMTP and POP3 servers. You may also configure various
parameters regarding sending mail.

For more information on the popusers and ftpusers (and alias)
files refer to Section 7.7, Other Files, where they are discussed
in more detail.


8.2  POP2/POP3

POP2 and POP3 server commands are not case sensitive. This
follows the Minnesota POP2D and Berkeley popper conventions. The
RFC specifies that the clients should only use upper case, but
there are stray clients that use lower case, so case
insensitivity was added.

The POP3 server includes Erik Olson's latest modifications so
that the LIST command works correctly with the latest NuPOP
release.

The POP3 server supports XTND and XMIT to send mail to POP3. This
addition (by Erik Olson) allows the use of POP3 to send and
receive mail in situations where SMTP access is restricted eg
from a campus dial-in terminal server.

8.3  SMTP

The SMTP server contains several enhancements. These include:

i) SOCKUSER.C was modified such that CONTROL-Z are stripped from
all ASCII socket transactions, preventing the abnormal
termination of a mailfile due to an embedded Control-Z in an
incoming message.

ii) Both MAIL FROM and RCPT TO commands are required before the
DATA command is accepted. Sender and recipient can be in any
order.

iii) The RESET command resets for the sender and the recipient
addresses, making it a true reset.

iv) To combat mail from auto-reply SMTP daemons gone awry, a kill
file is supported. Place addresses in the file (rootdir)MAILKILL
to reject mail from those senders (from DIS NET.EXE 2.11).

v) NOS will not accept mail for any user not in the FTPUSERS
file. There is however no restriction on the format of the
FTPUSERS file.

vi) SMTP server has some initial attempts at adding "."
transparency as required by RFC 821.


8.4  POP Mail Clients

A list of clients verified to work with the KA9Q pop2 and pop3
servers:

Macintosh:
  POPmail/Mac 2.0x:            pop2 and pop3 fetch
  Eudora 1.3x:                 pop3 fetch
  Eudora 1.4x:                 pop3 fetch
  Eudora 2.0x:                 pop3 fetch & send using XTND XMIT

DOS:
  POPmail/PC 3.x:              pop2 and pop3 fetch
  Minuet 1.0 Beta 16:          pop2 and pop3 fetch
                      note that sending long messages with beta 15
                      used to crash the KA9Q smtp server.  This was
                      fixed in beta 16.
  NuPOP 2.0x:                  pop2 and pop3 fetch & send using XTND XMIT
  NuPOP 2.10alpha:             pop2 and pop3 fetch & send using XTND XMIT
  COMMSET 1.0:                 pop3 fetch

Windows:
  PC Eudora 1.4x:              pop3 fetch
  PC Eudora 2.0x:              pop3 fetch & send using XTND XMIT
  WinTrumpet 1.0x:             pop3 fetch
  WinQVT/Net 3.9x:             pop3 fetch & send using XTND XMIT
  WinELM:                      pop3 fetch
  SuperTCP Mail 4.x:           pop2 and pop3 fetch

The client that Ashok prefers for Windows use is PC Eudora 2.0.2. 
Note that the pop3 clients that support sending mail using XTND XMIT
can be used over non-SLIP dialup links even if the terminal server
blocks connections to the SMTP port, since they use the POP3 port to
send mail.  This is a common security precaution against mail
forgery on most college dialin terminal servers.




9. The GOPHER SERVERS


9.1  SETTING UP

9.1.1  The Gopher Server

The KA9q NOS is capable of running two gopher servers. These are
called gopher and gopher2. In most cases it will be the first
gopher sever on port 70 which will be the one used as the sever.

Create a directory at the root level of your PC hard drive called
exactly "GOPHER".  This must be the same hard drive that contains
the server program: nos11a.exe. The rest of these instructions
assume that the hard drive is called C:  (if not, make the
necessary substitutions when reading this document).  The
contents of the directory C:\gopher (and any subdirectories
therein) will be available to gopher clients.

Create a file in the gopher directory called "ginfo".  This file
contains a description of the items in the gopher directory. 
Every subdirectory under GOPHER that you wish to display on the
Gopher server menu must have it's own "ginfo" file.

This sever is started with the command start gopher in the
autoexec.nos file. Its activity will be reported in the
gopher.log file. It listens on port 70.

9.1.2  The Gopher2 Server

The second gopher server is called GOPHER2. This sever uses
GINFO2 files located in the C:\GOFER2 directory and its
subdirectories. It listens on port 150.

Why add a second Gopher server? When combined with David
Mischler's IP packet filtering (see Section 12), the Gopher2
server can be used to selectively restrict access to certain
items on a Gopher menu by having those items reside on the second
Gopher server, and IP restricting that Gopher server. The second
Gopher server listens on port 150. The two Gopher servers are
compared below:

                                  Gopher                   Gopher2

Gopher Root Directory             /GOPHER                  /GOFER2
Index File                        GINFO                    GINFO2
Listens on port                   70                       150
CSO database file             (rootdir)CSO.DBF            (rootdir)CSO2.DBF
log-file                     ~/spool/gopher.log      ~/spool/gopher2.log
mail log file command          sendgopherlog           sendgopher2log
start server                    start gopher           start gopher2
stop server                      stop gopher            stop gopher2

Refer to section 12 for information on packet filtering.


9.2  GINFO FILES

9.2.1  Gopher Types

The gopher (and KA9Q) protocol uses two types of items, called
the client type and the server type. The client type is the
number that appears in the index immediately before the display
string. The server type after the <tab> after the display
string. The two types need not be the same.

The gopher protocol uses the following client types of items:

       0        = Item is a text file
       1        = Item is a directory
       2        = Item is a CSO (qi) PhoneBook server
       3        = Server Error
       4        = Item is a Macintosh Binhexed file
       5        = Item is a DOS Binary Archive of some sort
                  (see note(1) below)
       6        = Item is a uuencoded file
       7        = Item is an Index-Search Server
       8        = Item points to a text based telnet session
       9        = Item is a binary file, the client must read
                  until the tcp connection closes, beware
       +        = Item is a redundant server
       T        = Item points to a text based tn3270 session
       g        = Item is a GIF format graphics file
                  (see note(2) below)
       I        = Item is any kind of image file, the client
                  decides how to display
       i        = Item is an information line (Panda style)
       ;        = Item is a movie file
       s        = Item is a sound file
       m        = Item is a MIME file
       h        = Item is an HTML file

Note (1):  Not all clients recognize type '9'.  Therefore
           the auto-index function in the KA9Q server serves
           up all binary files as type '5'

Note (2):  Not all clients recognize type 'g'.  Therefore
           the auto-index function in the KA9Q server serves
           up all graphic files as type 'I'


The KA9Q server internally recognizes the following server
types:

     0 = ascii transfer (used with client file-types 0, 4, 6,
         and h)
     1 = directory
     7 = directory search
     9 = binary transfer (used with client file-type 5, I,
         s, ;, and m)
     s = menu file search
     p, q, z = DBF file searches
     "ph" or "query" = CSO style DBF search

Note: client type '7' is used with server types 7, s, and q

The following file extensions are used for the gopher types
listed:

exe, com, zip, arc, dll, wp, wb1, doc, zoo, hlp, ovr, ovl, lha,
tar are sent to the client as gopher type '5'

hqx is sent as gopher type '4'

uue is sent as gopher type '6'

bmp, jpg, tif, pcx, pic, xbm, wpg, pbm, jif are sent as gopher
type 'I'

gif is sent as gopher type 'g'

au, wav, and snd are sent as gopher type 's'

qt, mpg, dl, gl, and fli are sent as gopher type ';'

sub-directories and dbf are sent as gopher type '1'

all other files are sent as gopher type '0'  

Refer to section 9.4.2 for the gopher types used in the
mkginfo() function.


9.2.2 Ginfo File Structure

GINFO files are index files which are presented to the client.

Each line in the GINFO file describes an item.  The format of
each line is as follows:

<type><display string>TAB<type><file ident>TAB<host name>
TAB<port>

<type> is the gopher item type character.  Character 0 means
a file, 1 indicates a directory, etc. The first type is the
client type. The second type is the server type.

The <display string> is the string that will be visible to the
gopher client user.

The <file ident> is a curious beast:  it starts with the drive
name, say c:, followed by the full path of the file starting
INSIDE the gopher directory.  The directory separators can
either be slashes (as in UNIX) or the backslashes that Dos uses.
It is best to keep to the Unix convention and use the slash (/).

The TAB denotes an actual ASCII TAB character. Many common DOS
word processors strip out the tabs and replace them with
spaces; you need to leave the tabs inside.

It is important that the GINFO index files are terminated with a
single blank line with no characters is it, ie follow the last
entry in a GINFO with a single <CRLF>. The gopher server will do
the following for ASCII transfers:

a) type 0:  append "<CRLF>.<FF>" to the end of the file.

b) type 1:  append ".<FF>" to the end of the pre-existing GINFO
            file or the index that is created "on-the-fly".

c) type 2:  do nothing.

d) types 4 & 6: same as type 1.

Note that for all types the well behaved gopher clients should
strip the trailing period ".".


9.2.3  A Simple Ginfo File

An example ginfo file with three items (the # denotes an ASCII
TAB here and in all the other examples below):

--- begin ---
0About this Gopher#0c:/help.txt#foo.moo.umn.edu#70 ....... (1)
1An example directory#1c:/stuff#foo.moo.umn.edu#70 ....... (2)
1An example link##gopher.tc.umn.edu#70       ............. (3)
--- end ---

Item (1) -- This is a file (type character 0) that the user will
see as "About this Gopher".  The actual DOS full pathname of
this file is C:\gopher\help.txt.  The file ident here is
"c:/help.txt" (look at that carefully one more time). Note
that a type character precedes the file ident, and no tab is
between them. The file lives on this server, since this server's
name (foo.moo.umn.edu) and port (70 is the default gopher port)
follow.

Item (2) -- This item is a directory (type 1) that the user
will see as "An example directory".  The actual DOS full
pathname of this directory is C:\gopher\stuff.  The file
ident here is "c:/stuff".  Again, note the type character
right before it.  This directory too, lives on this server
as evidenced by the local name and port.

Item (3) -- This is also a directory.  The user will see
this as "An example link".  The directory is not on this
server at all; that is to say, it is a link to a directory
on another server.  In this instance, it  points to the
gopher server running on a machine called
gopher.micro.umn.edu at port 70.  Note the null selector
string.

If you wish users to be able to see items inside the
subdirectory (the second item), you will also have to
create a ginfo file in the C:\gopher\stuff subdirectory.
In other words, a ginfo file is a "gopher's view" of the
contents of any directory.

For more information on gopher item type characters, links,
etc., you should browse through the short document on the
internet Gopher protocol.  This is available via gopher or
by anonymous ftp from boombox.micro.umn.edu (look in the
/pub/gopher directory tree).

Some examples of Ashok's GINFO files are given below and in
the following sections.

(root directory for GOPHER)

--- begin ---
0About this Gopher#0c:/gopher.txt#biochemistry.cwru.edu#70
1POPmail, Gopher and other TCP/IP
programs#1c:/pop#biochemistry.cwru.edu#70
1Other Gophers and Information
Services#1c:/gopher#biochemistry.cwru.edu#70
1Search for E-mail Addresses#1c:/whois#biochemistry.cwru.edu#70
--- end ---


9.2.4  Downloading PC Binaries and Mac Binhex Files

An example is given below:

--- begin ---
0Read Me First#0c:/pop/readme.txt#biochemistry.cwru.edu#70
4Mac TurboGopher 1.05
(binhex)#0c:/pop/tgoph105.hqx#biochemistry.cwru.edu#70
5PC Gopher III (pkzip)#9c:/pop/pcg3.zip#
    biochemistry.cwru.edu#70
5Latest POPmail/PC
executable#9c:/pop/popmail.exe#biochemistry.cwru.edu#70
1Connect to BoomBox - Home of POPmail and
Gopher##boombox.micro.umn.edu#70
--- end ---

Note that when downloading PC Binaries, to maintain an open
TCP connection, a combination of item-type 5 & 9 is used.
In contrast, since Mac Binhexed files are ASCII, a
combination of 4 & 0 is used.


9.2.5  Links to Other Gophers and Telnet Links

Examples of links to other Gophers and Telnet links are
as follows:

--- begin ---
0Read Me First#0c:/gopher/readme.txt#
    biochemistry.cwru.edu#70
1Mother of All Gophers @ U. of Minnesota##
    gopher.tc.umn.edu#70
1Other Gophers through U of M.#1/Other Gopher and
    Information Servers#gopher.tc.umn.edu#70
8World Wide Web##info.cern.ch#23
8University of Saskatchewan HYTELNET#hytelnet#
    access.usask.ca#23
--- end ---

You can directly connect to a sub-menu at another Gopher
site. For Telnet connections, the TCP port is defined (in
this case it is port 23, the usual port for telnet). In
one case (World Wide Web) no username is required, and in
the other (Hytelnet), the user will be prompted to use the
login "hytelnet" when the item is selected.



9.2.6  A Wombat Example

The following example is from the wombat gopher server.
Note that 'wombat-host' was substituted for the full
host name 'wombat.es.mq.edu.au' only to get the full
line into 80 columns.

--- begin ---
0About This Gopher#0c:/gopher.txt#wombat-host#70
1About the School of Earth Sciences#1c:/school#
    wombat-host#70
0Announcing the School's WWW Server#0c:/es-www.txt#
    wombat-host#70
0Current Local Time#time#137.111.94.83#70
1Electronic Books, Journals, Serials and
Dictionaries#1c:/books#wombat-host#70
1Entertainment#1c:/games#wombat-host#70
1Gopher Subject Trees#1c:/trees#wombat-host#70
1Information on Topics#1c:/topic#wombat-host#70
1Internet, Campus and School Network
Documentation#1c:/interdoc#wombat-host#70
1Library Catalogs by Telnet#1c:/library#host#70
1Local Times Around the
World#1/general/time#gopher.austin.unimelb.edu.au#70
1Other Gophers#1c:/gophers#wombat-host#70
1Searches (WAIS, Jughead, Veronica, USGS ESDD)#
    1c:/searches#wombat-host#70
1Sites by Subject#1c:/subject#wombat-host#70
1Software#1c:/software#wombat-host#70
1Telnet Sites by Gopher#1c:/telnet#wombat-host#70
1Usenet News#1c:/nntp#wombat-host#70
1X.500 at MPCE, Macquarie Uni##macadam.mpce.mq.edu.au#
    7777
--- end ---


9.2.7  Special Note on Ginfo Files

i) The GINFO index files must be terminated with a single
   blank line with no characters in it.  i.e  follow the last
   entry in the GINFO file with a single <CRLF>.

Explanation: The Gopher server does the following for ASCII
transfers:
  
    a) type 0 -- append "<CRLF>.<FF>" to end of the file

    b) type 1 -- append ".<FF>" to the end of the pre-existing
       GINFO file or the index that is created "on-the-fly"

    c) type 2 -- do nothing

    d) types 4 & 6 -- same as type 1

Note that for all types the well behaved gopher client should
strip the trailing period "."

ii) The Ginfo file specifies the type and selector string that
gopher clients use to retrieve files and directories located
inside the PC's gopher directory. Naughty clients can not
manufacture a bogus selector string and attempt to climb
outside of the gopher directory tree, ie. the server will
not let them. In this respect, the server is secure.  However,
if a file or directory exists inside the gopher directory tree,
then even though the ginfo file does not explicitly advertise
it, if a client knows of its existence, it can manufacture a
selector string and successfully retrieve the file or directory.

iii) Ginfo files (or Menu or Index files) need NOT be called
GINFO, but can be called whatever you wish. Ashok gives an
example with his Gopher-Jewels where he uses *.mnu files.
These .mnu files have exactly the same structure as normal
ginfo files, with the exception that there is no trailing
blank line at the end of the file. So a main menu would have
the following entries:

--- begin ---
1Agricultural Gophers#0c:/jewels/agricult.mnu#your-host#port
1Biology Gophers#0c:/jewels/biology.mnu#your-host#port
--- end ---

Refer to a later section regarding more information on setting
up a subject gopher with gopher jewels.

iv) When a directory is accessed via Gopher, the KA9Q gopher
server currently has the following behavior:

a) if there is a 0 byte file called GINFO in that directory,
   then no directory is sent to the client

b) if there is a GINFO index file in that directory, then the
   contents of that GINFO file are sent to the client

c) if there is no file called GINFO, then an index is generated
   automatically, or "on-the-fly" and is sent to the client.
   Refer to a section 9.4 on the mkginfo() function.

v) If you wish to present Ginfo files on another disk drive,
   the files must be within a \gopher directory on that drive.


9.2.8  FTP Connections

Gopher allows for ftp connections, as an example use the following
link to the wais faq at MIT using the host at Washington and Lee:

1Wais FAQ#ftp:rtfm.mit.edu@/pub/usenet/news.answers/wais-
faq/getting.started# liberty.uc.wlu.edu#70

To the best of the author's knowledge, the KA9Q gophers do not
support these ftp connections.


9.2.9  ACCCESSING WWW HTML Files From GOPHER

The WWW is the World Wide Web. It uses files based on HTML,
or HyperText Markup Language. The WWW server is discussed in
section 13. This section discusses the methods of accessing
the WWW HTML files from gophers GINFO index files.

If the HTML file is being served up via GOPHER, then use
client  type 'h' and server type '0', as illustrated in the
following example of the GINFO entry:

eg. c:\gopher\test.htm

hHTML file#0c:\test.htm#gopher-host#70

If the HTML file is being served up via the KA9Q WWW server,
then the GET command is used with client type 'h', and the
www's port 80 is used. There are two cases, the GINFO
entries being:

case 1: default html file (c:\www\root.htm)
hRoot HTML file#GET /#host#80
                  ^^
case 2: some other html file within C:\WWW
-- c:\www\other\test.htm
hOther HTML file#GET /0c:\other\test.htm|/#host#80


9.3  Type 7, SEARCH ITEMS

There are three types of searches which are possible using
type 7. These are text file, menu file and dbf database
searches. Other searches can be used within the CSO sever
discussed in the next section.


9.3.1  Text File Searches

The first search engine within the gopher is capable of
"grepping" through a directory of text files and select
those files that match a particular search string, as the
following two example show:

     a) Search through all the files in the directory
     C:/GOPHER/FILES

     7Sample File Search#7C:/FILES/#gopher-host#70

     b) Search through only *.TXT files in the directory
     C:/GOPHER/FILES

     7Selective File Search#7C:/FILES/*.TXT#gopher-host#70

For these text-file searches there are a number of
limitations:

     i) there is a minimum length of 3 characters

     ii) if a file called BADWORDS.TXT is placed in the
     same directory as the nos executable, then no searches
     can be performed on any words in this file. Text in
     BADSWORDS.TXT is not case-sensitive.



9.3.2  Menu File Searches

A second search engine will also search through a file of
menu items eg a file that is a concatenation of ginfo
files, and returns the entries that match. They will only
search the descriptor string in a case insensitive manner.
This is called a Menu File Search. As an
example:

     0This is a text file#0c:/text#gopher-host#port
      -------------------
     Only this underlined portion will be searched.

To search through a gopher directory, all of the ginfo files
must be concatenated into a larger file, and placed within
the \GOPHER or \GOFER2 directory.

This large concatenated file can be created from Steven
Kliepzig's MAKESEARCH program (anonymous ftp to
ssb1.saff.utah.edu).

For example, if the \GOPHER directory contains the file ginfo.dir,
which has been created using MAKESRCH, then the ginfo entry to
search this file would be:

    7Search Directory Headings#sc:/gopher.dir#gopher-host#70

For these menu file searches there are a number of
limitations:

     i) there is a minimum length of 3 characters

     ii) if a file called GOPHER.BAD is placed in the same
         directory as the nos executable, then no searches
         can be performed on any words in this file. Text
         in GOPHER.BAD is not case-sensitive.

Refer also to the section on setting up a subject tree for
a similar application to a menu file search.


9.3.3  DBF File Searches

The third type of search engine can search through dBase III and dBase
IV files in the .DBF format. If you do not want the gopher client to be
able to search with some particular keywords, then place the file
DBFWORDS.TXT with those words in the same directory as the NOS
executable. The minimum search string length is 3 characters.

Two type of searches are possible. The search type "p" is where any field
in the .DBF database file can be searched. The second search type, "q",
will only search a nominated field of the data base file.

For example, consider a database file called SAMPLE.DBF. This is located
in C:/GOPHER/DATABASE. It has the following 4 fields: NAME, COUNTRY, AGE
and STATUS.

A "p" type search of any field in the data base will have an entry of:

7DBF Search of Any Field#pc:/database/sample.dbf#host#port

A "q" type search of only the field NAME would have an entry of:

7Search by NAME only#qc:/database/sample.dbf~NAME#host#port

Several people emailing the KA9Q email list have reported that some
software which produce .DBF format files appear to shift fields on
character position following a numeric type field. .DBF format files
created with Quattro Pro, FoxPro, Clipper and dBase are known to be free
of this error.


9.3.4  Tips on Search Exclusions

An exclusion list of words that wouldn't be allowed can be placed
in the appropriate file. Searches can be restricted by substring
searches of the illegal keywords file.

Good words to place in these exclusion files would be small words
like:

        and but for with out why when from path

Avoid compound words in these exclusion files. Here is an example
of a BADWORDS.TXT file:

---begin badwords.txt----
        and not but for with what how when why that this there
        article: from: reply-to: path: header:
        bionet.molbio.methds-reagnts
---end badwords.txt----

Line 1 makes the search pattern "and" "not" etc illegal keywords,
note that it does NOT make the search pattern "Tom and Jerry"
illegal.

However, keywords of "his", "here", "her", "hen", "hat" etc are
illegal as they are substrings of "this", "there", "there", and
"when". The search pattern "his and her" is valid.

Line 2 makes "article:" etc illegal, and so "art", "arti",
"artic", "tic" etc will also be illegal. But strings like
"article: 4068" is legal.


9.3.5  Setting Up a Gopher Subject Tree

The Gopher Jewels menu at biochemistry.bioc.cwru.edu has been
updated to the latest release of David Riggins' Gopher Jewels
list from cwis.usc.edu, and converted the menus to KA9Q format. 
The bookmark to the list is:

        Name=Gopher Jewels
        Type=1
        Port=70
        Path=1c:/jewels
        Host=biochemistry.bioc.cwru.edu
        URL=gopher://biochemistry.bioc.cwru.edu/11c:/jewels

Ashok has made it possible for people to setup a gopher jewels
on their own server by FTPing the Gopher Jewels index files from
biochemistry.bioc.cwru.edu.

Here is the relevant information:

        ftp-host: biochemistry.bioc.cwru.edu
        username: gopher
        password: jewels

This will put you directly in /gopher/jewels.  There is one GINFO
file in that directory, with several *.MNU files each of which
is the index for a separate Gopher Jewels area.  The file ALL.MNU
is a concatenated version of each of the individual menu files. 
The only file that you will have to edit is the GINFO file, to
replace "biochemistry.bioc.cwru.edu" with the  hostname/ip-
address of your Gopher site.

The Ginfo entry for the wombat jewels is as follows:

--- begin ---
0About Gopher Jewels#0c:/trees/jewels/jewels.txt#wombat-host#70
7Search all Gopher Jewel Sites (all
catagories)#sc:/trees/all.mnu#wombat-host#70
1Gophers with Subject Trees#0c:/trees/jewels/subject.mnu#wombat-
host#70
1Agriculture and Forestry#0c:/trees/jewels/agri.mnu#wombat-
host#70
--- end ---


9.3.6  Other Search Examples

Ashok has developed two other interesting applications of "s"
type searches on his gopher.

Case 1:

The University of Virginia EcoLibrary (ecosys.drdr.virginia.edu)
has the chemical factsheets for about 350 chemicals, and has a
directory which each menu item being an individual chemical. 
Unfortunately the entire list is not searchable by chemical name,
which makes it unwieldy to use when you are searching for a
particular chemical.

To get around this, their entire menu was saved as a menu file,
and made that menu-file searchable on cwru gopher, using the "s"
type search engine.  Check the following bookmark:

        host: biochemistry.bioc.cwru.edu
        port: 70
        type: 7
        path: sc:/database/msds.mnu


Case 2:

There are many other cases where it would be very useful to have
a searchable menu.  For instance, the University of NotreDame has
a large list of sites with phonebooks, while MIT has a large list
of sites with WHOIS servers.  While the phonebook list is
searchable at NotreDame, the Whois server list is not searchable. 
So I downloaded both menus to a single searchable menu file. 
Check the following bookmark:

        host: biochemistry.bioc.cwru.edu
        port: 70
        type: 7
        path: sc:/email/whois-pb.mnu

So now with a single search, all Whois and PhoneBook sites can
be searched for the name of the institution.  The total number
of institutions on both lists combined is close to 500, but
search speed is well within acceptable limits.


9.4 AUTO-INDEX GENERATION

9.4.1 The MKGINFO() FUNCTION

When a directory is accessed via Gopher, the KA9Q gopher
server currently has the following behavior:

a) if there is a 0 byte file called GINFO in that directory,
   then no directory is sent to the client

b) if there is a GINFO index file in that directory, then
   the contents of that GINFO file are sent to the client

c) if there is no file called GINFO, then an index is generated
   automatically, or "on-the-fly" and is sent to the client.
   The function that generates this index is mkginfo(), This
   function is based on file extensions it recognizes and is
   capable of presenting a large number of file-types to the
   client (see below).

Automatic index generation is useful in situations where
directories have numerous additions and deletions of files
and the constant altering of the GINFO would become a
tedious task. A good example would be a directory of software
and documntation archives

The mkginfo() function will automatically generate a ginfo
index file and send it to the client. The index file
generated will have the following characteristics:

- All files (except menu.cat) and subdirectories will be
  included as menu entries in the automatically generated
  index file.

- The gopher types presented to the client and server is
  dependent upon the file extension. It is assumed the file
  extension used corresponds to the actual format type of the
  file presented.

- The display string presented to the gopher client will be
  the name of the file or subdirectory.
  
- In the case of a .dbf file, a type p search of the database
  is assumed and the display to the gopher client will be
  'Search filename.dbf';

- If a previously generated index file called menu.cat is
  present, its contents will be appended to the "on-the-fly"
  index before it is sent to the client.


9.4.2 GOPHER TYPES in the MKGINFO FUNCTION

The following is a listing of the file-types recognised by
the mkginfo() function, and the client types and server
types used in the automatically generated index or ginfo
file:

- Client type 5; Server Type 9; File extensions zip, arc,
  arj, zoo, lha.

- Client Type 9; Server Type 9; File extensions exe, com,
  dll, hlp, ovl, ovr, z, taz, tgz, tar, doc, wp, wb1, wri,
  msw.
               
- Client Type 4; Server Type 0; File extension .hqx.
                 Note that Stuffit (.sit), Self-Extracting
                 Archive (.sea) and Compact-It (cpt)
                 Macintosh files should be BinHexed
                 (.hqx) before being archived for pickup.

- Client Type 6; Server Type 0; File extension uue.

- Client Type I; Server Type 9; File extensions gif, bmp,
  jpg, jif, tif, pcx, xbm, pic, pbm, eps, rle, icn, ico,
  wpg.

- Client Type ;; Server Type 9; File extensions qt, dl, mpg,
  qtw, fli.

- Client Type s; Server Type 9; File extensions au, wav,
  snd, sou.

- Client Type 1; Server Type p; File extension dbf.
                 Note that this results ins a search of the
                 .dbf file.

- Client Type 1; Server Type 1; File Type <sub-directory>.
                 Note that the gopher will access the
                 subdirectory.

- Client Type 0; Server Type 0; default files.


As an example, consider that subdirectory c:\gopher\files
has the following files:

readme.doc, bird.gif, flight.mpg, and email.dbf, and the
subdirectory c:\gopher\files\new

There is no ginfo file in this subdirectory.

When this subdirectory is accessed by gopher, the
mkginfo() function will create the following ginfo
file on the fly and send it to the client:

--- begin ---
9readme.doc#9c:/files/readme.doc#our-gopher#70
Ibird.gif#9c:/files/bird.gif#our-gopher#70
;flight.mpg#9c:/files/flight/mpg#our-gopher#70
1Search email.dbf#pc:/files/email.dbf#our-gopher#70
1new#1c:/files/new#our-gopher#70
--- end ---



9.4.3 The MENU.CAT FILE

There is a restriction imposed on generating an index
file which consists only of the files and subdirectories
present. If any other entries need to be present, they
can only be located in a ginfo file in a subdirectory. To
overcome this, the contents of a previously generated index
file can also be sent to the client along with the
"on-the-fly" index. This file is the MENU.CAT file.

Not only does the mkginfo() function generate an index for
all the files and sub-directories "on-the-fly", a previously
generated index file can also sent to the client.  This file
must be called "menu.cat".  If the file is not present, no
action is taken.  If the file is present, then the index within
this file is appended to the automatically generated index, and
sent to the client as a single menu.

For example, consider the previous example of the subdirectory
c:\gopher\files with the files readme.doc, bird.gif, flight.mpg,
email.dbf and a subdirectory c:\gopher\files\new. If a file
called menu.cat is added to the subdirectory, and menu.cat
contains the following two lines:

--- begin ---
2Our Phonebook##our-gopher#105
1Connect to Some Other Gopher##other-gopher#70
--- end ---

Then the following index will be sent to the client:

--- begin ---
9readme.doc#9c:/files/readme.doc#our-gopher#70
Ibird.gif#9c:/files/bird.gif#our-gopher#70
;flight.mpg#9c:/files/flight/mpg#our-gopher#70
1Search email.dbf#pc:/files/email.dbf#our-gopher#70
1new#1c:/files/new#our-gopher#70
2Our Phonebook##our-gopher#105
1Connect to Some Other Gopher##other-gopher#70
--- end ---


9.4.4 AN AUTO-GENERATED INDEX EXAMPLE

Ashok has several directories on his gopher server which
are nothing but files. Since he wanted to present these
directories via Gopher, and these directories have frequent
additions and deletions of files, generating an "on-the-fly"
index which is sent to the client seemed to be the way to go.
There is no GINFO file in c:\gopher\pub\nos and
c:\gopher\pub\nos\sliputil. The indexes for both subdirectories
are both created automatically before being sent to the
client.

One of these directories "c:\gopher\pub\nos" contains the
KA9Q gopher executables, help files, other utilities etc.
However, the documentation for the KA9Q NOS is located on
another server (Mark Johnson's gopher server). It seemed
appropriate that menu pointer that directs users to the
gopher documentation at Mark's gopher be presented in the
same menu as documentation.  Without the MENU.CAT file,
the only way to do this was to create a subdirectory called
c:\gopher\pub\nos\manual, then place the following GINFO
in that directory:

1Detailed KA9Q manual#1c:\manual#mark's_gopher#70

This is tedious from the client's perspective, i.e it
would take two menu selections to get to the manual, when
it should just take one.

So as part of the "on-the-fly" index function, the special
filename category (called "MENU.CAT") was used. This file
contains the above  pointer to Mark's server. When the
mkginfo() function sees this filename, then it opens the
file, reads the index line in the file, and appends that
line to the "on-the-fly" index before that index is sent
to client.

Note that the "menu.cat" item is of value exclusively when
the "on-the-fly" index function is used (i.e there is no
GINFO present in the directory).

Check out the following bookmarks:

host: biochemistry.bioc.cwru.edu
port: 70
type: 1
path: 1c:/pub/nos

and

host: biochemistry.bioc.cwru.edu
port: 70
type: 1
path: 1c:/pub/nos/sliputil

The last item on both menus is created using the menu.cat
file  present in those directories.

All other items are generated "on-the-fly", there is no GINFO.



10. The CSO SERVERS

Three CSO Servers may be run within the gopher server. These are run
from within the Gopher server, the CSO server and the Gopher2
server. These listen on ports 70, 105 and 150 respectively. The CSO
data base these servers access should be in dBASE III or dBASE IV
format. The Gopher server accesses (rootdir)CSO.DBF, where (rootdir)
is the directory that NOS is executed from.  Similarly, the CSO
server accesses (rootdir)CSO1.DBF and the Gopher2 server accesses
(rootdir)CSO2.DBF.

As the gopher servers access the various CSO databases from the
subdirectory in which the NOS is executed, it is important to be in
the C:\NOS subdirectory when executing the NOS executable, and not
from the root, or any other, directory. Your NOS.BAT file should be
similar to:

       cd c:\nos
       nos.exe -d/nos

and not like the following:

       c:\nos\nos.exe -d/nos

As with other TCP servers, the CSO server must be started with a
"start cso" command.
 
Having 3 CSO servers enables the search of multiple CSO databases on
the same server.

The three servers are compared below:

i) Server on port 70

       start command: start gopher
       stop command: stop gopher
       cso database: (rootdir)CSO.DBF

ii) Server on port 105

       start command: start cso
       stop command: stop cso
       cso database: (rootdir)CSO1.DBF

iii) Server on port 150

       start command: start gopher2
       stop command: stop gopher2
       cso database: (rootdir)CSO2.dbf

The CSO servers at port 70, 105, and 150 support "query=item",
"ph=item", "query field=item" and "ph field=item".

The CSO searches use gopher client type 2. The  following is an
example showing how each of the CSO servers are accessed:

--- begin ---
2Search the CSO Database##gopher-host#70
2Search the CSO 1 Database##gopher-host#105
2Search the CSO 2 Database##gopher-host#150
--- end ---





11. The TIME SERVER


The Gopher server can send the local time and date to gopher
clients, using the following GINFO index entry:

0Current Local Time#time#gopher-host#70

This sends the following text to the Gopher client:

Current date & time at "city":
Day, Month Date Year, hh:mm:ss TZ

"message"

For this to work correctly, two DOS environment variables must be
set (in autoexec.bat). The variables are "CITY", and "MESSAGE". CITY
must be 50 characters or less, and MESSAGE must be 100 characters or
less. If the variable CITY is not set, the text "this location" is
displayed in it's place. If the variable "MESSAGE" is not set, the
text "Have a nice day!" is displayed in it's place.

Network Time Protocol Client/Server (written by Giles Todd and Mark
Turner) from DIS NET211.EXE.  The client commands are "time
server|read|set etc. etc" and the server can be started with other
TCP servers (start|stop time).

For the NTP client to  work properly you must have a correct TZ
environment variable setting. The correct format is:

"set TZ=timezone(offset)daylight_savings_timezone" For example, for
the Eastern Standard Time time-zone. SET TZ=EST is incorrect
SET TZ=EST05EDT is correct

The set tz command for the wombat server (in Sydney, Australia) is:

SET TZ=EST-10GMT

-10 as we are 10 hours ahead of gmt. When we switch to daylight
saving time it becomes -11.

The SET CITY environment variable will display a user defined string
when used. An example CITY variable in the autoexec.bat file of the
wombat gopher is:

       SET CITY=Macquarie University, Sydney, Australia.

The SET MESSAGE will display a defined message after the time is
displayed. If it is omitted, then the default 'Have a nice day' is
displayed.


Time Client Commands

time delay <seconds>            - Sets a delay before the
                                automatic time setting and kick commands
                                are issued after connection. Default: 10
                                seconds.


time server <host | ipaddress>  - sets the time server

time read                       - gets the time

time set                        - sets the local PC clock to the remote
                                time

time maxcorrect n               - limit time correction to +n
                                seconds, 0 means no limit (default).

time mincorrect n               - limit time correction to -n
                                seconds, 0 means no limit (default).

time auto on/of                 - whether time is set on first IP
                                packet of new connection.


NTP Time Server Commands

start time                      - starts a time server on TCP port 37

stop time                       - stops the server

The 'start time' entry should be included in your autoexec.nos file
to start the NOS time server. The NTP sever on your net needs to be
specified in the autoexec.nos file with the 'time server your-nets-
ntp-server' command.

Once you set your PC clock using the NOS time client, the NOS time
server can provide very accurate GMT time to your local network.



12. PACKET FILTERING


12.1  INTRODUCTION and SUMMARY

David Mischler's code for packet filtering provides a great deal of
security to NOS. The code is quite sophisticated and can control
access to each individual listener with different IP restrictions
(see David's excerpt below). The IP packet filtering includes
optional logging to a SYSLOGD running on port 514 of any BSD
machine.

Apart from using IP packet filtering to restrict access to
particular servers in KA9Q such as SMTP and Telnet, IP packet
filtering can be used to restrict access to the second Gopher
server, thereby restricting access to specific menu items on the
primary Gopher server. An example is given below:

server with no restrictions: Gopher server on port 70
server with IP restrictions: Gopher2 on port 150 (only IP addresses
that begin with 129.22 are allowed to connect).

ip filter pk0 deny in tcpsys !129.222.0.0/16 129.22.152.44:150
ip filter pk0 permit in * * *
ip filter pk0 permit out * * *

The following example illustrates the implementation in a Ginfo
file:

--- begin ---
0Open CSO Searches#0c:/cso.txt#gopher-host#70      .........(1)
2Open Access CSO database##gopher-host#70          .........(2)
2Restricted Access CSO Database##gopher-host#70   ......... (3)
1Restricted Access directory#1c:/private#gopher-host#150 .. (4)
0Restricted Access File#0c:/file.txt#gopher_host#150....... (5)
0Open Access file#0c:/file.txt#gopher.txt#70       .........(6)
--- end ---

Item (1) -- provides access to the file c:/gopher/cso.txt
Item (2) -- provides access to the file (rootdir)cso.dbf
Item (3) -- controls access to the file (rootdir)cso2.dbf
Item (4) -- controls access to the directory c:/gopher2/private
Item (5) -- controls access to the file c:/gofer2/file.txt
Item (6) -- provides access to the file c:/gopher/file.txt


Packet Filtering can also be implemented to increase security when
setting up anonymous ftp servers. Refer to the section on NOS
SECURITY for more information.




12.2  DETAILED INFORMATION

David Mischler has implemented packet filtering for Phil Karn's
KA9Q software (930104 version) based on some of the ideas in
Brent Chapman's paper, "Network (In)Security Through IP Packet
Filtering".  Packet filtering is provided in most commercial IP
routers as a tool to assist in the implementation of network
security policies.

David would like some feedback from testers and other
knowledgeable people on bug reports, functionality and
performance.


WHAT CHANGED FROM KA9Q 930104

The package is standard KA9Q 930104 except that the SMTP modules
have been configured out, and an "ip filter" command has been
added.  The forms of the IP filter command are:

ip filter <interface> delete
ip filter <interface> list
ip filter <interface> deny <in/out> <type> <source> <destination>
ip filter <interface> permit <in/out> <type> <source> <destination>

The <interface> is the name of the interface that was assigned
when it was attached.

The "delete" command will delete the entire filter set for an
interface.

The "list" command will display the entire filter set for an
interface, and a counter for each filter entry that indicates the
number of packets that matched it.

The "deny" command will append a filter entry to the filter set
for an interface.  The direction of the packet to be disallowed
is from the perspective of the router running the filtering
process (i.e. "in" implies that the packet arrived on the
specified interface).  The type field specifies the packet
category to be disallowed.  The source and destination allow IP
addresses, address masks, and ports or port ranges to be
specified.

The "permit" command is identical to the "deny" command except
that it causes packets that meet the specified criteria to be
allowed.

The legal packet types are shown in the following table.

     TYPE                              MEANING

     *                         Any IP packet.

     icmp                      Any ICMP packet.
                    
     icmprd                    An ICMP REDIRECT packet.

     icmpxrd                   Any ICMP packet except a REDIRECT.

     tcp                       Any TCP packet.

     tcpsyn           A TCP packet with the SYN bit set and the
                      ACK bit clear. This implies an attempt to
                      open a new TCP connection.

     tcpxsyn          Any TCP packet that has the SYN bit clear or
                      the ACK bit set.  This implies a packet on
                      an existing connection.

     udp                       Any UDP packet.


A source or destination specification takes the form
[!]address[/bits][:port[+][-hiport]], where address is an IP
address in dotted octet form, or a resolvable domain name, or
"*".  The use of "*" for the address implies both an address and
address mask of all zeroes. If you specify "/bits" on an address
you are specifying how many of the high order bits of the address
are significant.  For example, to compare only the network part
of a class B address one could use /16. The use of "!" before an
address means that all addresses except those specified by the
address and mask match the specification.  Finally, if a port
number is specified then the filter entry will only match packets
with the appropriate port numbers (this is only meaningful if one
of the tcp, tcpsyn, tcpxsyn or udp packet types is specified). 
A single port number followed by a plus sign means all possible
port numbers greater than or equal to the specified port. Two
port numbers separated by a hyphen (minus sign) indicate a legal
port range.

The list of filter entries is scanned in the order they were
entered until a match is reached, then the action specified in
the filter entry (i.e. deny or permit) will be taken. If a packet
does not match any filter entries then it will be denied by
default. Note that the input and output filter sets are
independent and that, for example, if no output entries exist,
then all outgoing packets would be permitted.

If an IP datagram is fragmented then filters only apply to the
first fragment (all subsequent fragments are permitted). Incoming
and outgoing filters are checked even if source routing is
specified. These may not be ideal design decisions, so I would
especially appreciate feedback in these areas.

In the future better statistics and logging of denied packets
seem like worthy goals.  It may also be possible to add proxy
services for TCP & UDP (then again, maybe not).


SETTING UP FILTERS

This software will not magically solve your network security
problems. You have to know what you want to filter. In general,
I think it is best to allow only the services you actually need. 
For me, this means all outgoing TCP services, and incoming mail,
and finger for mailbox lookup.  In addition, DNS is needed for
name lookups, and I have to run NTP for political reasons (it
does not present any special security problem as far as I know).
Refer to Brent Chapman's paper previously cited for reasons not
to allow most UDP services, as well as RPC, NFS and NIS (yellow
pages) through your gateway.

Most TCP services are very simple to filter, and you really only
need to know the server port number.  This is true for TELNET
(23), SMTP (25), FINGER (79), and NNTP (119).  FTP is a little
tougher because after the client machine opens port 21 on the
server, the server uses its port 20 to open a non-privileged port
on the client. This has filtering implications.

DNS service is provided on UDP port 53 for most purposes, and on
TCP port 53 for zone transfers.  Most clients use UDP port 53,
but some use "random" non-privileged ports. NTP uses UDP port 123
on both ends for continuous update functions.

Here is a sample filter set for a fictional class C network
195.55.51.x to allow outbound TCP services, inbound mail to any
host, inbound finger to a single host, DNS (but no zone
transfers), and NTP. The Internet connection is on interface sl0. 
The line numbers are only for reference purposes.

1 ip filter sl0 permit in tcpxsyn !195.55.51.0/24  195.55.51.0/24
2 ip filter sl0 permit in icmpxrd !195.55.51.0/24  195.55.51.0/24
3 ip filter sl0 permit in udp !195.55.51.0/24:53   195.55.51.0/24:53
4 ip filter sl0 permit in udp !195.55.51.0/24:53   195.55.51.0/24:1024+
5 ip filter sl0 permit in udp !195.55.51.0/24:123  195.55.51.0/24:123
6 ip filter sl0 permit in tcpsyn !195.55.51.0/24:20   195.55.51.0/24:1024+
7 ip filter sl0 permit in tcpsyn !195.55.51.0/24   195.55.51.0/24:25
8 ip filter sl0 permit in tcpsyn !195.55.51.0/24   BIRD.WHIZZO.COM:79
9 ip filter sl0 deny   in  *   *   *
10 ip filter sl0 permit out *  195.55.51.0/24  !195.55.51.0/24

Line 1 permits TCP packets for established connections.  It
disallows attempts to spoof internal addresses from outside (the
other filter entries that allow arbitrary hosts also do this). 
There is probably a performance benefit from putting this rule
first.

Line 2 permits ICMP packets except redirects.

Line 3 permits UDP packets for DNS (server to server).

Line 4 permits UDP packets for DNS (server to client).

Line 5 permits UDP packets for NTP peer functions.

Line 6 permits FTP data connections from servers to non-
privileged client ports.

Line 7 permits new SMTP connections to be opened on any internal
machine.

Line 8 permits new FINGER connections to host BIRD.WHIZZO.COM
(probably 195.55.51.212).  Note that the domain name server had
better be working when ths command is executed or nobody will be
able to FINGER this BIRD.

Line 9 exists only so that the number of denied packets will be
counted (this rule duplicates the default).

Line 10 prevents internal hosts with invalid addresses, or
deliberate attempts at address spoofing, from getting to the
Internet.



13. The WWW SERVER


13.1  INTRODUCTION

The source code for the KA9Q HTTPd (WWW) server is based on the
KA9Q Gopher source code written by Chris McNeil (cmcneil@mta.ca). 
The KA9Q HTTP server has been successfully tested against the
following clients:

       Cello
       WinMosaic
       MacMosaic
       XMosaic
       Lynx
       SGI-Mosaic

This unexpected compatibility reflects the robustness of the WWW
clients, and the excellence of Chris McNeil's Gopher source code.


13.2  INSTALLATION

Create the directory \WWW on the same drive as the KA9Q
executable. All files must be present in this directory, or sub-
directories under it. If you wish to present files on another
disk-drive, as with the Gopher server, the files must be within
a \WWW directory on that drive.

In your AUTOEXEC.NOS file, along with the other TCP and UDP
servers, start the HTTP server with the command "start www"



13.3  SOME WWW TERMS

The following are some www terms that are sprinkled liberally in these
notes.

       WWW = World Wide Web

       HTTP = HyperText Transfer Protocol (the protocol used by clients and
       servers that use the WWW)

       HTML = HyperText Markup Language (the language in which files
       transferred to a WWW client have to be written)

       URL = Uniform Resource Locator (a pointer in HTML documents to
       another item, the other item may be another HTML document, another
       HTML server, a Gopher server, a mail-address, an FTP site, an Image
       file, a Sound file or something else).

This implementation of HTTP only transfers ASCII files (i.e the actual
HTML files), and not any binary files, such as sound or inline-image
files).  The latter are actually transferred using the GOPHER protocol,
by running a Gopher server on the same computer as the WWW server.


13.4  HTML FILES

The default HTML file that is returned to the client when it first
connects is the file drive:\WWW\ROOT.HTM. It is crucial that the name of
this file not be misspelled or changed.

All other HTML files may be named as desired, as long as the Dos
filename.extension (8.3) naming convention is not broken.

A URL that points to another HTML document on the server must begin with
the character "0" and must end with the characters "|/", or it will not
be fetched by the client.  For example, to point the client to the file
C:\WWW\TEST.HTM, the actual URL would read:

<A HREF="http://host/0c:/test.htm|/">Points to TEST.HTM </A>

As with the GOPHER server code, both front and back slashes are meant to
be equivalent. However, use of the Dos backslash in the path causes
errors for Unix WWW clients. So it is best to keep with the Unix
convention and use the forward slash, or "/".

The WWW root directory must be omitted from the pointer to the file.


13.5  IN-LINE IMAGES

Inline images are transferred using the Gopher protocol.  To keep things
straight, I would strongly recommend creating the directory
C:\GOPHER\WWWGIF and placing all inline GIFs in that directory and it's
sub-directory.

For instance, the GIF that is displayed in the root menu of the WWW site
biochemistry.bioc.cwru.edu is actually transferred to the client by a
Gopher request.  The URL entry in the HTML file (ROOT.HTM) reads as:

<IMG SRC="gopher://biochemistry.cwru.edu/I9c:/www/rsvpr.gif">

Note that there is no </IMG> tag as present in earlier versions of the
manual. This tag does not exist in standard HTML.


13.6  WWW CONNECTION TYPES

Valid www connection types (called schemes) for URL entries include:

i) http: for an http connection (a file on a WWW sever), eg

<A HREF="http://wombat.es.mq.edu.au/">Connect to Earth Sciences WWW
Server</A>
 School of Earth Sciences at Macquarie University<P>

ii) gopher: for a file on a gopher server or a gopher connection, eg

<A HREF="gopher://wombat.es.mq.edu.au:70/">Connect to the Earth
Sciences Gopher</A>
 the gopher server wombat.es.mq.edu.au at Macquarie University<P>

Note that gopher connections to the root ginfo file is simple,
connections to other subdirectories and files are a bit more
complicated, eg:

<A
HREF="gopher://wombat.es.mq.edu.au:70/11c%3a/interdoc/otherdoc/gis">
GIS Information from the Earth Sciences Gopher</A>  assorted GIS
information from UseNet Mail<P>

In the above example, what appears to be gibberish in the path
section of the URL, ie "11c%3a/gis", the first "1" refers to the
gopher type, second "1" indicates a path. The "%3a" says hex 0x3a
(ASCII 58), a single colon. Sometimes the hexadecimal number is used
for distinguishing non-alphunmeric characters in the path. Hex is
typically used to indicate space, slash, colon, underscore and the
like. 

iii) file: to retrieve a file on your local system or on an
anonymous ftp server, eg

<A HREF="file://jupiter.qub.ac.uk/pub/GIS/GIS.html"> A GIS Users
Guide to Internet Tools</A>
 from Queens University, Belfast<P>

iv) ftp: to retrieve a file on an anonymous ftp connection, eg

<A HREF="ftp://abraxas.adelphi.edu/pub/gis/FAQ"> Frequently Asked
Questions in GIS</A>
 FAQ from comp.infosystems.gis<P>

v) mailto:

This will open a dialog box to send mail to the user at the
specified address. Note that this is client dependent, it is not
supported by Mosaic. An example:

<A HREF="mailto:pingram@laurel.ocs.mq.edu.au">Phillip Ingram</A>

vi) news: to point to a newsnet news group

<A HREF="news:www/faq_764517493@rtfm.mit.edu"> WWW Frequently Asked
Questions</A>

Other URL schemes include telnet, rlogin and tn3270 for interactive
sessions, NNTP, prospero, whois amongst others. Refer to
file://info.cer.ch/pub/www/url-spec.txt for more information on
URLs.




13.7  LEARNING HTML

The KA9Q WWW server does not format documents on the fly, so all Web
documents must be formatted before hand. Note that this is a manual for
KA9Q NOS, not HTML.

The best way to learn HTML is to actually connect to an HTTP site such
as www.ncsa.uiuc.edu, and examine what their menus look like with a WWW
client like Mosaic.  Then retrieve the same menu by telnetting to port
80 (the Web port), and you get an idea of how the HTML formatting
translates to a nice Mosaic display. See also the examples of HTML in the
following section.

People should visit the following URL and learn about the HTML language:

http://www.ncsa.uiuc.edu/demoweb/html-primer.html

The following description is a very brief introduction to HTML.

i) Tags

HTML uses tags to tell the WWW viewer how to display the text. Tags
consist of a left angular bracket (<), the directive, and a right angular
bracket (>), eg <Title>. The directive tells what is to be done.

Tags are usually paired, eg <H1> and </H1>. The ending tag is like the
starting one excepts it has a slash. The formatting or directive
commences from the start tag and ceases at the end tag, eg

<H1>Some Text</H1>

The words 'some text' will be displayed in header style 1.

ii) Some Tags

Title:  <title>The Title</title>    Every html document should have a
title. 

Headings:  <Hn>A Heading</Hn>
   where n = 1 to 6 specifying the level of the heading.

Paragraphs: <P>
   Unlike other documents HTML does not recognise carriage returns and
white spaces. The WWW browser will insert a paragraph when it reaches the
<P> tag.


Unordered List:      <UL>
                     item 1
                     item 2
                     </UL>
Puts items in a list. Can be nested. For a bullet place a <LI> tag prior
to each item.

Ordered List:        <OL>
              item 1
              item 2
              </OL>
Similar to an unordered list, but numbers them. Can be nested.

Bold:   <b>this text is in bold</b>

Italics: <i>this text is in italics</i>

citation: <cite>this is a citation</cite>

Address:  This tag is used to specify the author of a document with an
email address. It is usually at the end of a document. End with a
</address>.

Thin Horizontal Gray Line: <HR>. This tag produces a this horizontal gray
line.

iii) Connections

Refer to the previous example for connection types in html. Refer to
Section 9.2.9 on accessing HTML files from gopher.


13.8  HTML EXAMPLES

13.8.1  The CWRU WWW ROOT.HTM

CWRU Biochemistry Department WWW server root (as on 1/12/94)
URL = http://biochemistry.bioc.cwru.edu/

--- begin ROOT.HTM ---
<header>
<title>CWRU Biochemistry Department Home Page</title>
</header>
<IMG SRC="gopher://biochemistry.cwru.edu:70/I9c:\webgif\rsvpr.gif">
</IMG>
<H1>Welcome to the CWRU Biochemistry Department World
Wide Web server</H1>
<p>
<UL>
<LI><A HREF="gopher://biochemistry.cwru.edu:70/1">
CWRU Biochemistry GopherServer</A><P>
<LI><A HREF="http://biochemistry.cwru.edu/0c:\ka9q.txt|/">
Information about the KA9Q Gopher and Web Server</A><P>
<LI><A HREF="http://www.ncsa.uiuc.edu/">
Connect to the NCSA WWW Server</A><P>
<LI><A HREF="gopher://gopher.cwru.edu:70/">
Connect to the CWRU Campus Gopher server</A>
<p>
<LI><A HREF="http://biochemistry.cwru.edu/0c:\ashok.txt|/">
Ashok Aiyar's Personal WWW Page</A> <p> <P><P>
This is an experimental Web server running at the CWRU
Department of Biochemistry on a 386 PC under KA9Q NOS.
This server was written by
<A HREF="mailto:ashok@biochemistry.cwru.edu">Ashok Aiyar</A>,
a graduate student in this department.</H7><P><P>
<I>The picture of the molecule on this page is that of the
retroviral protease. The structure of this molecule was
solved on account of pioneering work initiated within this
department! </I>
<P>
<hr>
<B>CWRU Medical School - Department of Biochemistry</B><P>
<ADDRESS>Harland Goff Wood Building<P> School of Medicine<P>
Case Western Reserve University<P> Cleveland, Ohio
44106-4935</ADDRESS></BODY>
--- end ROOT.HTM ---


13.8.2  The WOMBAT ROOT.HTM

The wombat WWW server:
URL = http://wombat.es.mq.edu.au/

Note that on this server the <LI> command is not used. Instead a gif
image of a 'white ball' is retrieved. This is purely for aesthetic
reasons. A cut down version of the ROOT.HTM for the wombat server is as
follows:

---begin ROOT.HTM for wombat ---
<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/earth4.gif">
<H2>School of Earth Sciences at Macquarie University</H2>
<H3>World Wide Web Server</H3>
<P>
<UL>
<P><P>
This is an experimental web server running at Macquarie University on a
386 PC under KA9Q NOS. This server was written by <A
HREF="mailto:pingram@laurel.ocs.mq.edu.au">Phillip Ingram</A>
(pingram@laurel.ocs.mq.edu.au), School Computing Officer.<P> <P><P>
<HR>
<h5>School Information</H5><P>
The main options are:<P>

<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/whitball.gif">
<A
HREF="gopher://wombat.es.mq.edu.au:70/00c%3a/school/earthsci.txt">Info
rmation on the
School of Earth Sciences</A><P><P>

<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/whitball.gif">
<A HREF="http://wombat.es.mq.edu.au/0c:/school.htm|/">Information on the
Areas within the School</A><P><P>

<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/whitball.gif">
<A HREF="gopher:://wombat.es.mq.edu.au:70/">Connect to the Earth Sciences
Gopher Server</A><P>

<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/whitball.gif">
<A HREF="gopher://wombat.es.mq.edu.au:70/2">CSO Phonebook</A>  search
staff CSO database for phone no., email address etc.<P>

<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/whitball.gif">
<A HREF="gopher://wombat.es.mq.edu.au:70/0time">Current Local Time</A>
<P>
<P>

<HR>
<H5>Information on Topics in the Earth Sciences</H5> Assorted information
on various Earth Sciences topics are accessed below:<P>
<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/whitball.gif">
<A HREF="http://wombat.es.mq.edu.au/0c:/geolinfo.htm|/"> Geological
Information</A> Information of a geological nature<P>
<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/whitball.gif">
<A HREF="http://wombat.es.mq.edu.au/0c:/gisinfo.htm|/"> GIS
Information</A> Information on Geographic Information Systems<P>
<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/whitball.gif">
<A HREF="http://wombat.es.mq.edu.au/0c:/geoginfo.htm|/"> Geographical
Information</A>
 Information of a geographical nature<P>
<IMG SRC="gopher://wombat.es.mq.edu.au:70/I9c:/webgif/whitball.gif">
<A HREF="http://wombat.es.mq.edu.au/0c:/climinfo.htm|/"> Climatological
and Meteorological Information</A>  Information on Climatology and
Meteorology<P>
<P><P>
<HR>
</UL>
</BODY>
--- End ROOT.HTM for wombat ---



13.8.3  An Example of Forms Processing

The KA9Q WWW server can present forms to the client, and the client can
interpret the form, and submit it, but the KA9Q WWW server has no CGI
capabilities and cannot process the form. To process forms, the form
needs to be submitted to another site for CGI interfacing. The following
HTML example is from the Library at Maquarie University, and the form is
submitted to the MPCE's www server for processing. This idea is from Glen
Darcy and Vince Scida from Macquarie University.

--- begin forms example ---
ELECTRONIC REQUESTING OF INTERLIBRARY LOANS <BR>
<p>
Customer wishing to take advantage of the automated Interlibrary
loans facilities, to request a copy of an original work must register
their intent to use this service by the completion of a "Copyright
Declaration for Electronic Requests" at the Inteteterlibrary loans
office. 
<p>
<HR>
A. TO REQUEST A BOOK ON INTERLIBRARY LOAN
<P>
1. Complete all sections of the following form.
<p>
2. Click on <b>Submit</b> to forward your request to the Interlibrary
Loan Office.
<HR>
B. TO REQUEST A PHOTOCOPY OF A CHAPTER OF A BOOK
<P>
1. Register to use the electronic requesting facility by completing
a  "Copyright Declaration for Electronic Requests" at the Interlibrary
Loan Office.<BR>
<P>
2. Complete all sections of the following form.<BR>
<p>
3. Click on <b>Submit</b> to forward your request to the
Interlibrary Loan Office.
<p>
<HR>
COPYRIGHT DECLARATION (Section 49(1) of the Copyright Ac). I require
this copy for the purpose of research or study and will not use it for
any other purpose. I have not previously been supplied with a copy of
this article or other work.
<HR>
<FORM METHOD="POST" ACTION="http://www.mpce.mq.edu.au/cgi-bin/sendbk.pl">

<h1>ILL REQUEST FORM</h1>

Please fill out the contact details before entering your request details.
<hr>
NAME : <input name="name"><br>
ID NUMBER : <input name="id"><br>
DATE : <input name="date" size=10><br>
SCHOOL : <input name="school"><br>
STATUS :
Staff<input name="status" TYPE=radio VALUE="Staff" CHECKED>
Masters<input name="status" TYPE=radio VALUE="Masters">
Honours<input name="status" TYPE=radio VALUE="Honours">
Phd<input name="status" TYPE=radio VALUE="Phd">
Diploma<input name="status" TYPE=radio VALUE="Diploma">
Supervisor<input name="status" TYPE=radio VALUE="Supervisor"> <br>
EMAIL : <input name="email"><br>
TELEPHONE : <input name="phone"><br>
<hr>
<B>MONOGRAPH REQUEST FORM</B><br>
AUTHOR/EDITOR : <input name="mauth"><br>
TITLE : <input name="mtitle"> <br>
PLACE OF PUBLICATION : <input name="mplace"> <br>
PUBLISHER : <input name="mpub"> <br>
DATE : <input name="mdate"> <br>
EDITION : <input name="medit"><br>
SOURCE OF REFERENCE : <input name="msource"><br>
NO LONGER REQUIRED AFTER (date of indefinite):<input name="mreq"
size=10><br>
IF CHAPTER ONLY REQUIRED AUTHOR/TITLE : <input name="mchap"><br>
<hr>
<p>
Press to : <INPUT TYPE="submit" VALUE="  Submit  ">
Press to :<INPUT TYPE="reset" VALUE="   Reset   "><p>
</FORM>
--- end forms example ---



14. The FTP SERVER

14.1  Introduction

FTP stands for File Transfer Protocol. The NOS KA9Q has an FTP
server so the host machine can act as an ftp server and an anonymous
ftp server which listens on port 21.

The ftp server is started with the "start ftp" command in the
autoexec.nos. FTP parameters in autoexec.nos include:

        ftype image              # FTP server default protocol binary
        ftpdisc 300              # 5 minutes (300 secs) of inactivity causes
                                 reset
        ftpmaxcli 5              # upto 5 FTP clients can connect
                                 simultaneously

There are security implications when setting up an anonymous ftp
server. Refer to the section on NOS SECURITY for further
information.



14.2  The FTPUSERS File

Each user of the ftp server requires an entry in the FTPUSERS file
(refer section 7.7.3). This file contains usernames with passwords
and the appropriate protection levels.

The format for each user for ftp/telnet access in the FTPUSERS file
is as follows:

       user password/directory_access_to protection_level

The protection levels include:

       1      - read access only
       3      - read/write but not delete
       7      - read/write/delete
       127    - remote sysop access
       128    - this user is banned from telnet access to mailbox


14.3  Other FTP Files

The file \NOS\SPOOL\FTP.TXT is an ASCII file that is displayed when
an ftp session is established as a pre-login message (type "220").

The MESSAGE.FTP files, located in each ftp accessible subdirectory,
is a message file that is automatically sent to the connecting FTP
client. This is a plain text file. The server will prefix every line
with "230- " or "250- " as is appropriate. According to the RFC,
"220" is to be used with a pre-login message, "230" is to be used
with a message associated with a login, and "250" is to be used with
a message associated with the "CWD" command.


14.4  Setting Up an Anonymous FTP Server

The desire here is to avoid duplicating the directory structure and
files to be presented by gopher and those to be made available by
anonymous ftp. The solution is make the public directory under
\gopher. So all executables will be located under \gopher\pub. This
will allow gopher and anonymous ftp to share a common directory
structure.

The entry in the FTPUSERS file would be

       anonymous * /gopher/pub 1


All files can the be presented alphabetically using Don Williams
CSAP software. The following lines in an autoexec.bat will run the
CSAP program ensuring a sorted presentation of files:

       cd \gopher\pub
       c:\utils\csap -N

All the files under \pub are presented using mkginfo().  Some of the
links within that hierarchy are presented making use of "menu.cat"
files.

Say for example the directory C:\GOPHER\PUB contains the following
files:

       word.exe
       help.txt
       files.zip
       new (sub-directory)

If someone tried to access that directory, then this is the menu
that the gopher server will automatically create that the user's
gopher client will interpret (<tabs> are represented by "#")

       1new#1c:/gopher/pub/new#gopher-host#70
       0help.txt#0c:/gopher/pub/help.txt#gopher-host#70
       5files.zip#9c:/gopher/pub/files.zip#gopher-host#70
       9word.exe#9c:/gopher/pub/word.exe#gopher-host#70


Now, let's say that in addition to this menu (which is automatically
generated) I also wish for the user to automatically see a pointer
to the "/pub" directory at another gopher-host, say for example
"boombox.micro.umn.edu".  Then, all I need to do is to place a file
called MENU.CAT into the directory c:/gopher/pub.  MENU.CAT needs to
have the *single* entry ...

       1Connect to BoomBox#1/pub#boombox.micro.umn.edu#70

All the files in c:/gopher/pub now are:

       word.exe
       help.txt
       files.zip
       menu.cat
       new (sub-directory)

The menu that is automatically generated to send to the user is:

       1new#1c:/gopher/pub/new#gopher-host#70
       0help.txt#0c:/gopher/pub/help.txt#gopher-host#70
       5files.zip#9c:/gopher/pub/files.zip#gopher-host#70
       9word.exe#9c:/gopher/pub/word.exe#gopher-host#70
       1Connect to BoomBox#1/pub#boombox.micro.umn.edu#70


MENU.CAT is not a replacement for the function that automatically
generates a gopher-menu for a directory of files.  It is instead
meant to augment that function.

So, you do not need to manually create GINFO files for directories
with large numbers of files -- the gopher server will do that
automatically.



15. NOS SECURITY


15.1  General Considerations

The main issue here is restricting anonymous access to the telnet
server. One big question about anonymous users in your telnet server
is: Do you want them there at all?  For most systems, why you'd want
anonymous users in your telnet server unless you want to keep a
public message area where anyone and telnet to your server and read
or post to that message area.

You can very easily ban anonymous users from the telnet server and
still give them access to the ftp server (see below).

Jon Lewis <jlewis@chem.ufl.edu> has setup a public message area. The
way he has things setup allows people with email addresses on the
system to get mail via pop3, or telnet in and read their mail and
send replies (if they really want to). Anonymous telnet logins, can
only read the 2 public areas, and can only send mail to those 2
public areas. The 2 areas are set to forward to themselves and to
Jon so he gets notified if anything shows up there.


15.2  Preventing Anonymous Access to the Telnet Server

If you allow anonymous FTP, you must make an entry for 'anonymous'
in the FTPUSERS' file with no password. Anyone can then telnet into
the machine, log in as anonymous, and send e-mail. To make the
machine secure you can:

1) Set the third-party mail flag off in AUTOEXEC.NOS:

third off

2) Set the mbox secure flag on in AUTOEXEC.NOS:

mbox secure on

3) Prevent telnet access from most machines using IP filtering:

ip filter pk0 deny in tcpsyn !129.22.152.0/24 129.22.152.44:23
ip filter pk0 permit in * * *
ip filter pk0 permit out * * *

(only machines from within 129.22.152.0 can telnet to this NOS
machine)

4) IP filtering on smtp port (25) so that undesirable computers are
denied access:

ip filter pk0 deny in tcpsyn !129.22.152.0/24 129.22.152.44:25

5) Loopback filters on the smtp port (25). The loopback filters
ensure that anonymous doesn't telnet in from a known machine, and
send anonymous mail by telnetting to port 25 of the NOS machine.

ip filter loopback deny in tcpsyn 127.0.0.1/32 127.0.0.1:25
ip filter loopback permit in * * *
ip filter loopback permit out * * *

As a final precaution you should also examine the mail logs and
investigate anything suspicious.


15.3  Setting up a Public Message Area

The following information is from Jon Lewis and describes how he has
setup a public message area.

>
> I have third party mail turned off, but is there a way I can
>set it up so I can telnet in and send mail out? I've tried setting
>my account to "remote sysop" (127) in ftpusers, but I still
>can't...

#mbox secure on
mbox maxmsg 600
mbox expert off
mbox password itsasecret
#third-party off
mbox motd "Press A to see a list of areas.  A areaname to change
areas."

As you can see, I no logner use mbox secure, or third-party off.  I
think it's better to handle this in ftpusers with:

#  1   Read files
#  2   Create new files
#  4   Overwrite and delete existing files
#  8   AX.25 gateway operation allowed
#  16  Telnet gateway operation allowed
#  32  NET/ROM gateway operation allowed
#  64  Remote sysop access allowed (DANGEROUS)
#  128 This user is banned from BBS access (illegal user)
#  256 Priv bit for PPP connection
#  512 Priv bit for peerID/pass lookup
# 1024 disallow send commands (except to SYSOP)
# 2048 disallow read commands
# 4096 disallow 3rd party mail
# 8192 This station is a known BBS

# I get 1 2 4 16 64
# there's no reason for others to telnet out of my system...so they
can't

jlewis itsasecret / 87
# incoming can create and is banned from BBS aka telnet server aka
mailbox
incoming * /incoming 130 
salewis itsasecret /gopher/pub 19
gnorton itsasecret /gopher/pub 19

#anonymous gets 1 2 4096, can read, create, and disallow 3rd party
mail
anonymous * /gopher/pub 4099

#ftp can read, create, and is banned from bbs
ftp * /gopher/pub 131

#[alias's]

# these are aliases that can recieve mail but have it forwarded
elsewhere
# they need no access at all and get none, they probably don't even
need
# passwords, i.e. could be *, but I've not bothered to test that

postmaster itsasecret / 128
webmaster itsasecret / 128
slewis itsasecret / 128
norton itsasecret / 128

#[public message areas]

# these entries are needed so nos and general can receive mail, but
people
# can't log in using these names

nos * /gopher/pub 128
general * /gopher/pub 128



16. NOS TESTING

The following is a response from Ashok to someone who could
not get some of the NOS servers to work.

Q:  Until now the only KA9Q service I have used is Gopher.
This has been running well for 6 months.  I have just attempted
to use telnet, ftp, finger, and pop.  FTP works the rest does
not.  Seems like I must be  missing something very basic.
Any ideas?

A:  I just tried to telnet to your gopher at port 25, and
access was blocked. This suggests that your IP filtering is
not permitting me in (I could gopher in).

Anyway try the following from the NET> prompt.

Telnet 127.0.0.1 110
and 
Telnet 127.0.0.1 25

With the first one, once you get the pop3 login which will
look something like ...

OK biochemistry.bioc.cwru.edu POP3 ready for action

enter the following command
user mark
to which the response will be 
+OK user
then
enter the command
pass password

If that works, the response will be +OK you have ## messages

See if that works.  If that works, then KA9Q can read your
POPUSERS file.

Repeat the same with SMTP.  The Banner will be something like

220 biochemistry.bioc.cwru.edu Ka9Q SMTP server ready

Try the following command ...
rcpt to:<mark>
if it says
250 Ok

then that means it can read your FTPUSERS file, and the problem
is some mistake in IP filtering which is cutting off access
from other machines to your SMTP server and  POP3 server..

BTW, you NEVER want other machine not to be able to  access
your SMTP server or you will never be able to receive mail.
In my sample filtering file, the example was to shut off SMTP
access from very specific machines from the CWRU campus --
namely machines like the dialin terminal server, machines in
student dorms, and some communal computing labs.  All other
machines on and off campus have full access.  I notice that I
also cannot do a traceroute or ping your machine ..... so I
really suspect packet filtering problems.



17. OTHER APPLICATIONS FOR KA9Q NOS


17.1 KA9Q as a Mail Router with News

This section is from the document '/lan/.comp.sys.novell/36270'.

>I was looking for a way link a novell net to internet for email and
>usenet newsfeeds.  I was thinking about using a dialup slip or uucp
>connection (I wanted to connect during "non-prime-time" to cut the cost of
>the link).  I worked with Pegasus and Charon a few years back but then I had
>direct access to internet for the gateway.  At that time Pegasus and Charon
>didn't not support newsfeeds (I haven't dropped a copy for a couple of years
>they may now.) An earlier post to this thread suggests "DIP" on a Linux
>host.  I had hoped to avoid droping a UNIX host in to my net but I guess
>thats the way to go.  Can someone point the direction to find "DIP"
>or some similar software.  I particular for access to news feeds.

Sorry about the previous repost of the un-editted message.

There is a version of KA9Q on ftp.demon.co.uk (/pub/ibmpc/nonet/)
and a Pegasus user defined gateway (/pub/ibmpc/gw/) which will allow
it's use as an SMTP mail to Pegasus mail gateway.  It is much more
sophisticated than the Charon gateway in it's handling of SMTP.  It
can also grab news using NNTP (passive feed mode - newnews and
article commands) although you will need a newsreader which can
handle C-News (RFC 1036) uncompressed batches.  There are several in
the comp.os.msdos.mail-news FAQ.  CPPNews (shareware) and the Demon
version of SNEWS (freeware) are
both available on the above server. KA9Q is shareware.


17.2 KA9Q as a TCP/IP Router for Novell Servers

This section is from the document '/lan/.bit.listserv.novell/36940'.

>>I gotten iptunneling to work between two sites. It doesn't seem that stable.
>>I can use the connection several times, 2, then reload the peer list. Any
>>suggestions? Thanks...
>>
>
>If you get any suggestions, can you please forward.  I'm trying to do the
>same now and it appears somewhat buggy.

I have proplem using IPTUNNEL. Our network topology is like below.


             Ethernet                       Ethernet
   +-------+  |                                   |  +-------+
   |Netware|--+                                   +--|Netware|
   +-------+  |                                   |  +-------+
              |                                   |
              |  +----+  SLIP  9600bps    +----+  |
              +--|Ka9q|...................|Ka9q|--+
              |  +----+   leased line     +----+  |
              |                                   |

Any time i use IPTUNNEL to login remote netware(3.11) server it is good for 10
minutes(Reasonably Slow) then it hangs up & more sever problem is that
Destination Netware Server also hangs up.I use ODI & LWP tcp stack as
Client TCP/IP software. i use 'Ka9q NOS' as IP router.

I need IPTUNNEL for operation on remote server console using RCONSOLE.



17.3 JNOS as a BootP Server

A version of KA9Q exists for the purpose of setting a pc up as a bootp
server. This is jnos110b.exe and it has bootp and bootpd commands built
in. It is available from mvangel.npt.nuwc.navy.mil in /public/tcpip/110b.
This NOS does not have the built in gopher and WWW servers as the nos11*,
but it does have a more sophisticated handling of overload situations.


17.4  The NOS11CJ Version

The NOS11CJ version was modified from Nos11c, with portions added to it
from Nos11c-a, by Jon Lewis. It has had the gopher, gopher2 and http
servers from nos11c ported over, as well as the CSO and DBF servers. At
the current time some of these servers are not fully tested.

- One of the main changes was in the ftpserv.c code. JNOS does not
implement the MaxTransfers in nos11c which limits the number of file
transfers per anonymous ftp session.

- binwarn in the FTP server has been added to warn users trying to
transfer binary files in ASCII mode that they should switch to binary,
and the transfer will fail. A binwarn failure will also be logged in the
logfile.

- The syst command in ftpserv is implemented.

- Changes to the reporting in the ftp server log file. It will now report
when someone connects and tell the remote user the number of anonymous
and regular users are currently connected.

- The gopher server has been modified to show message.ftp

- The mkginfo function was altered to display the filename, size and
date.

- The maximum number of packet drivers was increased from 4 to 5 so a 4
line slip server is possible.

- When nos runs low on memory the system will reboot, rather than writing
a memory request failure to the log file. If using a loop in a .bat file,
care should be taken to ensure nos loads in the proper state after an
unscheduled reboot.

.
