








                     KA9Q NOS


                   USER MANUAL

                     for the

                  KA9Q CWRU/BIOC

             Network Operating System









                                      June, 1994




CONTENTS

1.  INTRODUCTION

2.  ACKNOWLEDGEMENTS

3.  AVAILABLE LITERATURE

4.  ADDITIONAL SOFTWARE SOFTWARE5

5. RELEASE NOTES For 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 SERVE
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 TESTING

16. OTHER APPLICATIONS For KA9Q NOS
        16.1  KA9Q as a Mail Router with News
        16.2  KA9Q as a TCP/IP Router for Novell Servers


1.  INTRODUCTION


KA9Q 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


This manual is a compilation from various sources and people. It is
the manual for NOS11C-A.EXE, the current version of the executable
of the KA9Q NOS as at June, 1994. This is available from
biochemistry.bioc.cwru.edu either by anonymous ftp (evenings only)
or by Gopher (any time).

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. Ashok currently
maintains the KA9Q code, as well as a KA9Q mailing list.

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.



2.  ACKNOWLEDGEMENTS


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>

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>

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.


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 KA9 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 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 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. This service is maintained
by Mark Johnson <mark@cases.pubaf.washington.edu>.


iii)  The following usenet news groups:

               comp.infosystems.gopher
               comp.infosystems.www
               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 retrive 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


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 in biochemistry.bioc.cwru.edu, port 70, in path
1c:/pub/nos/utils/uqamutil. You need to be bilingual in French and
English.



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.

i) Ethernet Packet Drivers: The latest Crynwr (& old Clarkson)
packet drivers are available from oak.oakland.edu in
/pub/msdos/pktdrv

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) To configure KA9Q as a SLIP server, use SLIPLOG by Karl-Heinz
Weiss. This is an access control program for a slipgate for use with
a modem. It may be used for any ibmpc-gatesoftware which uses packet
drivers and has been tested with ka9q nos (nos192 and nos10b only).
It is available by ftp from: mvmpc9.ciw.uni-karlsruhe.de
(129.13.118.9) in /public/nos/sliplog.zip.

vi) MAKESRCH by Steven R. Klepzig creates a summary of the gopher
directory and saves this summary in a GINFO file. MAKESRCH is
located on ssb1.saff.utah.edu in pub/gopher/server/ka9q.

vii) 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.

viii) 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.

ix) 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.

x) 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.

xi) 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.

xii) 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.

xiii) 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.

xiv) For the monitoring of the KA9Q NOS, Steve Klepzig has
suggested:

     a) Have running on your server. This does an IPX "ping" every
     couple of minutes for selected machines.  It tells you when
     your KA9Q machine really dies and doesn't respond to an IPX
     "ping".

     b) Using OS/2's TCP/IP there's an IP based PMPing program that
     will do a PING on a defined time period of selected stations. 
     It reports when the IP ping is not replied to and also the
     round trip time for the ping.



5. RELEASE NOTES For CWRU/BIOC NOS


The current version of the 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) Optimized 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.


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



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 execuatble 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 the
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.


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.


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.

What it does:

        -polls the modem for incoming rings
        -switches to auto-answer
        -sends a greeting message to the caller
        -prompts for a password
        -switches to packetmode after a successful login
        -logs all calls with time and date
        -can call-back the caller (increased security)
        -patches the slipdriver, so no packets are send when not
        connected (this increases the stability of the gatesoftware
        and the modem) 

SLIPLOG may be useful for any ibmpc-gatesoftware which uses
packet-drivers, but has been tested with ka9q-nos (nos192 and
nos10b) only.

You may ftp it from: mvmpc9.ciw.uni-karlsruhe.de (129.13.118.9)
in /public/nos/sliplog.zip
(ws_ftp-users should select 'ka9q' as servertype!)


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"



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 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 serach 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



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


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 = Unique 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 DOS 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
equivalent, and 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"></IMG>



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/interdoc/otherdoc/gis",
is actually interpretable. The first "1" refers to the
gopher item type, the second "1" is the start of the path,
like 1/pub/filename, and the "%3a" is compulsory,it just
needs to be there. The rest is the normal path.

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>.

iii) Connections

Refer to the previous example for connection types in html.


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. An 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"></IMG>
<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>
<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\greyline.gif">
</IMG>
<h5>School Information</H5><P>
The main options are:<P>

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

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

<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\greyline.gif">
</IMG>

<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">
</IMG>
<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"><
/IMG>
<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">
</IMG>
<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">
</IMG>
<A HREF="http://wombat.es.mq.edu.au/0c:/climinfo.htm|/">
Climatological and Meteorological Information</A>
 Information on Climatology and Meteorology<P>
<P><P>
<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\greyline.gif">
</IMG>
</UL>
</BODY>
--- End ROOT.HTM for wombat ---


13.8.3  The WOMBAT GEOLSITE.HTM

Another example of html from wombat is the cut down version
of the geolsite.htm file:

--- begin geolsite.htm for wombat ---
<H4>Geological Web Sites</H4>
<P><P>
<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\greyline.gif">
</IMG>
<UL>
<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF="http://info.er.usgs.gov/">
United States Geological Survey</A>
 Connect to the USGS WWW Server, information on geology,
geography, GIS, climate and much more<P>
<UL>
<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF=
"http://info.er.usgs.gov/network/science/earth/earth.html">
USGS - Earth and Environmental Science</A>
  go straight to other connections in Earth and Environmental
sites<P>
<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF=
"http://info.er.usgs.gov/network/science/earth/earthquake.html">
USGS - Earthquake Sites</A>
 go straight to other connections for Earthquake sites<P> </UL>

<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF="http://stoner.eps.mcgill.ca/">
McGill University, Dept of Earth and Planetary Sciences</A>
  gopher and ftp sites, Canadian Superconducting Gravimeter
data<P>

<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF="http://www.gsf.fi/"> Geological Survey of Finland</A>
  GSF activities, regional offices, links to Finnish and
foreign services<P>

<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF="http://info.mcc.ac.uk/Geology/home-page.html">
Manchester University, Dept. of Geology</A>
  department information, research, undergrad and postgrad
courses<P>

<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF=
"http://www.gly.bris.ac.uk/"> University of Bristol</A>
 local information, Mac stuff, geological & other
internet connections<P>

<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF="http://www.ngdc.noaa.gov/ngdc.html">
The National Geophysical Data Centre</A>
  repository for global data in fields of solar-terrestrial
physics, solid earth geophysics, marine geology & geophysics,
glaciology<P>

<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF="http://ldeo.columbia.edu/">
Lamont-Doherty Earth Observatory of Columbia University</A>
 resources on climate, MG & ampG database, IRIS/PASCAL
Instrument Center,  multibeam synthesis, MB system software<P>

<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\whitball.gif">
</IMG>
<A HREF="http://www-erl.mit.edu/">
MIT Earth Resources Laboratory</A>
 applied geophysics as it relates to tectonophysics, seismology, 
environmental engineering and parallel computing<P>
<P>
</UL>
<IMG SRC=
"gopher://wombat.es.mq.edu.au:70/I9c:\webgif\greyline.gif">
</IMG>
</BODY>
--- end geolsite.htm for wombat ---



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


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 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.



16. OTHER APPLICATIONS FOR KA9Q NOS


16.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.


16.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.



