+++ /dev/null
-<!doctype linuxdoc system>
-
-<article>
-
-<!-- Title information -->
-
-<title>The DXSpider Installation Manual v1.50</title>
-<author>Iain Philipps, G0RDI (g0rdi@77hz.com),
-Ian Maude, G0VGS, (g0vgs@gb7mbc.net) and Charlie
-Carroll, K1XX, (k1xx@ptcnh.net)</author>
-<date>February 2003 revision 0.6</date>
-
-<abstract>
-A reference for SysOps of the DXSpider DXCluster program.
-</abstract>
-
-<!-- Table of contents -->
-<toc>
-
-<!-- Begin the document -->
-
-<sect>Linux Installation
-
-<sect1>Introduction
-
-<P>
-This section describes the installation of DX Spider v1.50 on a
-<htmlurl url="http://www.redhat.com" name="RedHat"> Linux Distribution.
-Wherever possible I will try to include differences for other distributions.
-
-<P>
-I am assuming a general knowledge of Linux and its commands. You should
-know how to use <em>tar</em> and how to edit files using your favourite editor.
-
-<P>
-The crucial ingredient for all of this is
-<htmlurl url="http://www.perl.org" name="Perl">. Earlier versions of
-Spider required perl 5.004, however it is now <it>STRONGLY</it> recommended
-that you use at least version 5.005_03 as this is the version being used
-in the development of Spider.
-
-<P>
-In addition to the standard Red Hat distribution you will require the
-following modules from <htmlurl url="http://www.cpan.org/modules/by-module/" name="http://www.cpan.org/modules/by-module/"> , please note however that with later versions of perl, some of these
-modules may be included with the distribution. Get the modules anyway and try
-to install as below. If they complain, they are probably already a part of your
-perl distribution.
-
-<P>
-<itemize>
-<item> <htmlurl url="http://www.cpan.org/modules/by-module/Data/Data-Dumper-2.10.tar.gz" name="Data-Dumper-2.101.tar.gz">
-<item> <htmlurl url="http://www.cpan.org/modules/by-module/Date/TimeDate-1.10.tar.gz" name="TimeDate-1.10.tar.gz">
-<item> <htmlurl url="http://www.cpan.org/modules/by-module/IO/IO-1.20.tar.gz" name="IO-1.20.tar.gz (for perl 5.00403 and lower)">
-<item> <htmlurl url="http://www.cpan.org/modules/by-module/Net/Net-Telnet-3.03.tar.gz" name="Net-Telnet-3.03.tar.gz">
-<item> <htmlurl url="http://www.cpan.org/modules/by-module/Curses/Curses-1.06.tar.gz" name="Curses-1.06.tar.gz">
-<item> <htmlurl url="http://www.cpan.org/modules/by-module/Time/Time-HiRes-01.20.tar.gz" name="Time-HiRes-01.20.tar.gz">
-<item> <htmlurl url="http://www.cpan.org/modules/by-module/Digest/Digest-SHA1-2.01.tar.gz" name="Digest-SHA1-2.01.tar.gz">
-</itemize>
-
-<P>
-Copy the CPAN modules listed above to a convenient place on your computer. One good
-place would be /usr/local/packages, and the instructions which follow will assume that
-that's where you have put them.
-
-<P>
-Log in as 'root', and make sure you're at '/root' before you continue. Here are exactly the commands you must issue next: -
-
-<verb>
-# tar xvfz /usr/local/packages/Data-Dumper-2.101.tar.gz
-# cd Data-Dumper-2.101
-# perl Makefile.PL
-# make test
-# make install
-# cd ..
-#
-# tar xvfz /usr/local/packages/TimeDate-1.10.tar.gz
-# cd TimeDate-1.10
-# perl Makefile.PL
-# make test
-# make install
-# cd ..
-#
-# tar xvfz /usr/local/packages/IO-1.20.tar.gz
-# cd IO-1.20
-# perl Makefile.PL
-# make test
-# make install UNINST=1
-# cd ..
-#
-# tar xvfz /usr/local/packages/Net-Telnet-3.03.tar.gz
-# cd Net-Telnet-3.02
-# perl Makefile.PL
-# make test
-# make install
-# cd ..
-#
-# tar xvfz /usr/local/packages/Curses-1.06.tar.gz
-# cd Curses-1.06
-# perl Makefile.PL
-# make test
-# make install
-# cd ..
-#
-# tar xvfz /usr/local/packages/Time-HiRes-01.20.tar.gz
-# cd Time-HiRes-01.20
-# perl Makefile.PL
-# make test
-# make install
-# cd ..
-#
-# tar xvfz /usr/local/packages/Digest-SHA1-2.01.tar.gz
-# cd Digest-SHA1-2.01
-# perl Makefile.PL
-# make test
-# make install
-# cd ..
-</verb>
-
-<P>
-Do not fall into the trap of thinking they're all the same, just because they
-nearly are! Pay particular attention to the instructions of <em>IO</em>, above.
-
-
-<sect1>Preparation
-
-<P>
-I will assume that you have already downloaded the latest tarball of
-the DXSpider software and are ready to install it. I am assuming version
-1.50 for this section but of course you would use the latest version.
-
-<P>
-Login as root and create a user to run the cluster under. <bf><it>UNDER
-NO CIRCUMSTANCES USE ROOT AS THIS USER!</it></bf>. I am going to use
-the name <em>sysop</em>. You can call it anything you wish. Depending
-on your security requirements you may wish to use an existing user,
-however this is your own choice.
-
-<tscreen><verb>
-# adduser -m sysop
-</verb></tscreen>
-
-<P>
-For SuSE distributions, the command would be ..
-
-<tscreen><verb>
-# useradd -m sysop
-</verb></tscreen>
-
-<P>
-Now set a password for the user ...
-
-<tscreen><verb>
-# passwd sysop
-# New UNIX password:
-# Retype new UNIX password:
-passwd: all authentication tokens updated successfully
-</verb></tscreen>
-
-<sect1>Installing the software
-
-<P>
-Now to unpack the DX Spider distribution, set symbolic links and group
-permissions. Copy the tarball to /home/sysop and do the following.
-
-<tscreen><verb>
-# cd ~sysop
-# tar xvfz spider-1.50.tar.gz
-# ln -s ~sysop/spider /spider
-# groupadd -g 251 spider (or another number)
-</verb></tscreen>
-
-<P>
-If you do not have the command <em>groupadd</em> available to you simply
-add a line in /etc/group by hand.
-
-<tscreen><verb>
-# vi /etc/group (or your favorite editor)
-</verb></tscreen>
-
-<P>
-You also need to add some others to the group, including your own callsign
-(this will be used as an alias) and root. The finished line in /etc/group
-should look something like this
-
-<tt>
-spider:x:251:sysop,g0vgs,root
-</tt>
-
-<P>
-The next step is to set the permissions on the Spider directory tree and files ....
-
-<tscreen><verb>
-# chown -R sysop.spider spider
-# find . -type d -exec chmod 2775 {} \;
-# find . -type f -exec chmod 775 {} \;
-</verb></tscreen>
-
-<P>
-This last step allows various users of the group <em>spider</em> to have
-write access to all the directories. This is not really needed just yet
-but will be useful when web interfaces start to appear.
-
-<P>
-Finally, you need to fix the permissions on the ax25_call and netrom_call
-programs. Check where they are with the <em>locate</em> command and alter
-the permissions with the <em>chmod</em> command like this ..
-
-<tscreen><verb>
-# chown root ax25_call netrom_call
-# chmod 4775 ax25_call netrom_call
-</verb></tscreen>
-
-<sect1>Setting callsigns etc
-
-<P>
-Now login to your machine as the user you created earlier. In my case that
-user is called <em>sysop</em>. Once logged in, issue the following commands ....
-
-<tscreen><verb>
-$ cd /spider
-$ mkdir local
-$ mkdir local_cmd
-$ cp perl/DXVars.pm.issue local/DXVars.pm
-$ cd local
-$ vi DXVars.pm (or your favourite editor)
-</verb></tscreen>
-
-<P>
-Using the distributed DXVars.pm as a a template, set your cluster callsign,
-sysop callsign and other user info to suit your own environment.
-
-<tscreen><verb>
-$mycall = "GB7DJK";
-</verb></tscreen>
-
-<P>
-This is the call sign of your cluster. If you use an SSID then include it here
-also.
-
-<tscreen><verb>
-$myalias = "G1TLH";
-</verb></tscreen>
-
-<P>
-This is the sysop user callsign, normally your own.
-
-<P>
-<bf>PLEASE USE CAPITAL LETTERS FOR CALLSIGNS</bf>
-
-<P>
-Note that this a perl file which will be parsed and executed as part of the
-cluster. If you get it wrong then perl will complain when you start the cluster
-process. It is important only to alter the text of any section. Some of the
-lines look a little odd. Take this line for example ....
-
-<tt>
-$myemail = "ianmaude\@btinternet.com";
-</tt>
-
-<P>
-There appears to be an extra slash in there. However this has to be there
-for the file to work so leave it in.
-
-<P>
-DON'T alter any file in /spider/perl, they are overwritten with every
-release. Any files or commands you place in /spider/local or /spider/local_cmd
-will automagically be used in preference to the ones in /spider/perl EVEN
-while the cluster is running!
-
-<P>
-Save the new file and change directory to ../perl ....
-
-<tscreen><verb>
-$ cd ../perl
-</verb></tscreen>
-
-<P>
-Now type the following command which creates the basic user file with you as
-the sysop.
-
-<tscreen><verb>
-$ ./create_sysop.pl
-</verb></tscreen>
-
-<sect1>The client program
-
-<P>
-In earlier versions of Spider, all the processes were Perl scripts. This
-was fine but with a lot of users your computer memory would soon be used up.
-To combat this a new client was written in "C". This client only works for
-<em>incoming</em> connects at the moment. Before you can use it though it
-has to be "made". CD to /spider/src and type <em>make</em>. You
-should see the output on your screen and hopefully now have a small C program
-called <em>client</em>. Leave it in this directory.
-
-
-<sect1>Starting up for the first time
-
-<P>
-We can now bring spider up for the first time and see if all is well or not!
-It should look something like this ...
-
-<tscreen><verb>
-$ ./cluster.pl
-DXSpider DX Cluster Version 1.50
-Copyright (c) 1998 Dirk Koopman G1TLH
-loading prefixes ...
-loading band data ...
-loading user file system ...
-starting listener ...
-reading existing message headers
-reading cron jobs
-orft we jolly well go ...
-</verb></tscreen>
-
-<P>
-If all is well then login on another term or console as <em>sysop</em> and
-cd to /spider/src. Now issue the following command ...
-
-<tscreen><verb>
-$ ./client
-</verb></tscreen>
-
-<P>
-This should log you into the cluster as the sysop under the alias callsign we
-set earlier. In this case the callsign is G0VGS. The cluster callsign is set
-in the DXVars.pm file in /spider/local. In this case we will assume that this
-was set as GB7MBC. You should therefore see this when you login ....
-
-<tscreen><verb>
-G0VGS de GB7MBC 19-Nov-1999 2150Z >
-</verb></tscreen>
-
-<P>
-If you do, congratulations! If not, look over the instructions again, you
-have probably missed something out. You can shut spider down again with the
-command ....
-
-<tscreen><verb>
-shutdown
-</verb></tscreen>
-
-<P>
-and both the cluster and the client should return to Linux prompts.
-
-
-<sect>Linux quick installation guide
-
-<P>
-This section is designed for experienced Spider sysops who want to install
-Spider from scratch. It is simply a check list of things that need to be
-done without any explanations. The name in brackets at the end of each line
-is the user that should be doing that process.
-
-<itemize>
-<item>Login as root
-<item>Get the additional CPAN modules and install them (root)
-<item>Create the "sysop" user and set a password (root)
-<item>Put the Spider tarball in ~sysop and untar it (root)
-<item>ln -s ~sysop/spider /spider (root)
-<item>groupadd -g 251 spider (root)
-<item>Add any more users you need to the group entry in /etc/group (root)
-<item>Set the permissions on the spider tree (root)
-<item>Fix permissions on ax25_call and netrom_call (root)
-<item>Login as the sysop user
-<item>cd to /spider (sysop)
-<item>mkdir local (sysop)
-<item>mkdir local_cmd (sysop)
-<item>cp perl/DXVars.pm.issue local/DXVars.pm (sysop)
-<item>cd to /spider/local and edit DXVars to set your details (sysop)
-<item>cd ../perl (sysop)
-<item>./create_sysop.pl (sysop)
-<item>./cluster.pl (sysop)
-</itemize>
-
-<P>
-Spider should now be running and you should be able to login using the
-client program.
-
-<itemize>
-<item>Login as root
-<item>Enter the correct line in ax25d.conf (root)
-<item>Enter the correct line in /etc/services (root)
-<item>Enter the correct line in /etc/inetd.conf (root)
-<item>killall -HUP inetd (root)
-</itemize>
-
-<P>
-Spider should now be able to accept logins via telnet, netrom and ax25.
-
-<itemize>
-<item>Login as sysop
-<item>Start the cluster (sysop)
-<item>set/node and type for links (sysop)
-<item>Write any connect scripts (sysop)
-<item>Edit /spider/crontab as required (sysop)
-<item>Edit any other files as necessary (sysop)
-<item>Set filters, hops and forwarding files (sysop)
-<item>Login as root
-<item>Enter the correct line in /etc/inittab (root)
-</itemize>
-
-<sect>Setting up the AX25 Utilities
-
-<P>
-The aim of this section is not to fully cover the installation
-and configuration of all the possible ax25 modules. I will
-attempt to cover a simple installation and configure 2 serial
-ports as if they had TNC's on them. I will also show what
-additional configuration the DXSpider program requires.
-
-<P>
-Please bear in mind that I am basing this section on a RedHat
-7.1 distribution, if you are using SuSe or any other distibution
-then your mileage may vary. I will be happy to make any changes
-and additions if you email me any errors or distribution specific
-requirements.
-
-<P>
-You would probably benefit from reading the <htmlurl url="http://www.fokus.gmd.de/linux/HOWTO/html_single/AX25-HOWTO.html#AEN151" name="AX25-HOWTO"> which is much more
-comprehensive and an interesting configuration program is also available
-called <htmlurl url="http://1409.org/projects/index.html" name="ax25-config"> which
-may help you to configure things.
-
-<P>
-The following files are extracts from the working files at GB7MBC and
-are in daily use. However, there are many ways that you can configure the
-ax25 utils, this is just the one I use, it does not mean it is necessarily
-the best or for that matter, the right way!
-
-<sect1>Getting Started
-
-<P>
-There are 2 things you need to do initially. You need to get the
-3 files required for the ax25 installation and you need to make
-some changes to the kernel configuration.
-
-<P>
-The first thing is to get the versions of the ax25 utils that match
-your kernel. You may also wish to get a node package of some kind.
-There are 2 main node packages in use of which I shall keep to the
-original by Tomi Manninen, OH2BNS as this is included in the ax25
-rpms as standard. The other is <htmlurl url="ftp://ftp.funet.fi/pub/ham/packet/linux/awznode/" name="AWZNode"> by IZ5AWZ.
-
-<P>
-NB: The AX25 stuff in 2.4 kernels appears to have been broken until 2.4.18. I
-strongly suggest you get at least this kernel.
-
-<P>
-For 2.4 kernels you need these files...
-
-<P>
-<itemize>
-<item> <htmlurl url="ftp://ftp.rpmfind.net/linux/redhat/7.1/en/powertools/i386/RedHat/RPMS/libax25-0.0.7-7.i386.rpm" name="libax25-0.0.7-7.i386.rpm">
-<item> <htmlurl url="ftp://ftp.rpmfind.net/linux/redhat/7.1/en/powertools/i386/RedHat/RPMS/ax25-tools-0.0.6-13.i386.rpm" name="ax25-tools-0.0.6-13.i386.rpm">
-<item> <htmlurl url="ftp://ftp.rpmfind.net/linux/redhat/7.1/en/powertools/i386/RedHat/RPMS/ax25-apps-0.0.4-9.i386.rpm" name="ax25-apps-0.0.4-9.i386.rpm">
-</itemize>
-
-<sect1>The kernel
-
-<P>
-First you need to add Amateur Radio Support to your kernel. This is
-a main menu item and should be easily found. Within this header you
-will find lots of options. For our purposes you need to enable
-Amateur Radio AX.25 Level 2 Protocol, NET/ROM and the Serial Port
-KISS Driver. For the purposes of this document I will work under the
-assumption that you include them in the kernel fully, ie not as modules.
-If you need to look at compiling your kernel for ax25 more fully, I would
-refer to the excellent
-<htmlurl url="http://www.fokus.gmd.de/linux/HOWTO/html_single/AX25-HOWTO.html#AEN151" name="AX25-HOWTO">
-
-<P>
-I should say at this stage that NET/ROM is not mandatory. If you do not use it
-simply ignore any instruction concerning it.
-
-<P>
-Now recompile your kernel in the normal way and reboot your system.
-
-<sect1>Installing the RPM's
-
-<P>
-Now install the RPM's you downloaded, libax25 first, then ax25-tools,
-then ax25-apps.
-
-<tscreen><verb>
-rpm -ivh libax25-0.0.7-7.i386.rpm
-rpm -ivh ax25-tool-0.0.6-13.i386.rpm
-rpm -ivh ax25-apps-0.0.4-9.i386.rpm
-</verb></tscreen>
-
-<sect1>Configuration
-
-<P>
-You will find the configuration files in /etc/ax25. These consist of
-several files ...
-
-<itemize>
-<item>axports
-<item>nrports
-<item>nrbroadcast
-<item>ax25d.conf
-<item>node.conf
-</itemize>
-
-<P>
-These are the main files. You will find other files but they do not
-have any use unless you are wanting to use that particular protocol,
-Rose or axip for example.
-
-<P>
-NOTE:- before we start it is important to realise that every interface
-requires a different SSID. You should be able to follow this in the
-following examples.
-
-<sect1>axports
-
-<P>
-This file sets up the ax25 ports you want to use. An example is below
-for a standard TNC2 ...
-
-<tscreen><verb>
-#portname callsign baudrate paclen window description
- 2m gb7mbc-2 19200 256 2 2m port on 144.900MHz
- 4m gb7mbc-4 19200 256 2 4m port on 70.325MHz
-</verb></tscreen>
-
-<P>
-Note that the portnames have to be unique.
-
-<P>
-The file headings are as follows ...
-
-<verb>
-portname - The name you will refer to the port by
-callsign - The ax25 callsign you want to assign to the port
-baudrate - The speed you communicate between TNC and computer
-paclen - The maximum packet length for ax25 connections
-window - The ax25 window parameter. This is like 'maxframe'
-description - A textual description of the port
-</verb>
-
-<sect1>nrports
-
-<P>
-This file sets up the netrom ports you want to use. An example is below
-and includes a port for both cluster and node. You will see why we need
-2 ports later ...
-
-<tscreen><verb>
-#portname callsign alias paclen description
- netrom gb7mbc-8 BARE 236 Node Netrom Port
- netrom2 gb7mbc-9 MBCDX 236 Cluster Netrom Port
-</verb></tscreen>
-
-<P>
-Note that the portnames have to be unique.
-
-<P>
-The file headings are as follows ...
-
-<verb>
-portname - The name you will refer to the port by
-callsign - This is the callsign that NET/ROM traffic from this
- port will use
-alias - The NET/ROM alias this port will be assigned
-paclen - The maximum size of NET/ROM frames transmitted
-description - A textual description of the port
-</verb>
-
-<sect1>nrbroadcast
-
-<P>
-This file sets up the netrom broadcast qualities. An example is below ...
-
-<tscreen><verb>
-#axport min_obs def_qual worst_qual verbose
- 4m 5 10 100 1
-</verb></tscreen>
-
-<P>
-The file headings are as follows ...
-
-<verb>
-axport - The port name in axports that you wish to broadcast
- NET/ROM on.
-min_obs - The minimum obsolescence value for the port
-def_qual - The default quality for the port
-worst_qual - The worst quality for the port. Any routes under
- this quality will be ignored
-verbose - This flag determines whether you will only broadcast
- your own node (0) or all known nodes (1)
-</verb>
-
-<sect1>ax25d.conf
-
-<P>
-This file controls any incoming ax25 and NET/ROM connections and steers
-them to the relevant program. There are lots of configuration options
-you can set here, however they are well covered in the AX25-HOWTO. For
-our purposes I will show a typical set of parameters. An example is
-below ...
-
-<tscreen><verb>
-[gb7mbc-0 via 2m]
-parameters 2 1 6 900 * 15 0
-NOCALL * * * * * * L
-default * * * * * * - sysop /spider/src/client client %u ax25
-
-[gb7mbc-1 via 2m]
-parameters 2 1 6 900 * 15 0
-NOCALL * * * * * * L
-default * * * * * * 0 root /usr/sbin/node node
-
-[gb7mbc-0 via 4m]
-parameters 2 1 6 900 * 15 0
-NOCALL * * * * * * L
-default * * * * * * - sysop /spider/src/client client %u ax25
-
-[gb7mbc-1 via 4m]
-parameters 2 1 6 900 * 15 0
-NOCALL * * * * * * L
-default * * * * * * 0 root /usr/sbin/node node
-
-<netrom2>
-parameters 1 10 * * * 3 *
-NOCALL * * * * * * L
-default * * * * * * - sysop /spider/src/client client %u ax25
-
-<netrom>
-parameters 1 10 * * * 3 *
-NOCALL * * * * * * L
-default * * * * * * 0 root /usr/sbin/node node
-</verb></tscreen>
-
-<P>
-There are a few things to take note of here. Firstly, all ax25
-sections are wrapped in [ ] and all NET/ROM sections are wrapped in
-< >. Secondly you should be able to see that anyone who forgets to
-set their callsign in a TNC and tries to connect with the standard
-NOCALL set into their TNC will not connect, the 'L' means 'lockout'.
-Lastly and importantly, notice the order of the sections. They are
-all done in interface order.
-
-<P>
-You should be able to see that the normal line for access to the
-cluster is like this ..
-
-<tscreen><verb>
-default * * * * * * - sysop /spider/src/client client %u ax25
-</verb></tscreen>
-
-<P>
-however, if you wish your users to be able to use SSID's on their callsigns ..
-
-<tscreen><verb>
-default * * * * * * - sysop /spider/src/client client %s ax25
-</verb></tscreen>
-
-<P>
-For most purposes this is not desirable. The only time you probably will
-need this is when you need to allow other cluster nodes that are using SSID's
-in. In this case it would probably be better to use the first example and
-then add a specific line for that node like this:
-
-<tscreen><verb>
-GB7DJK-2 * * * * * * - sysop /spider/src/client client gb7djk-2 ax25
-default * * * * * * - sysop /spider/src/client client %u ax25
-</verb></tscreen>
-
-<sect1>node.conf
-
-<P>
-For those of you that wish to run the node, you need to set up the
-node.conf file. There are a couple of additional files, node.perms is
-very similar to the way ftp permissions are set up in NOS systems and
-node.motd is the message anyone logging into the node will get.
-The node.conf file sets all the parameters of the node as you would
-expect. An example is below ...
-
-<tscreen><verb>
-# /etc/ax25/node.conf - LinuxNode configuration file
-#
-# see node.conf(5)
-
-# Idle timeout (seconds).
-#
-IdleTimeout 1800
-
-# Timeout when gatewaying (seconds).
-#
-ConnTimeout 40000
-
-# Visible hostname. Will be shown at telnet login.
-#
-HostName gb7mbc.ampr.org
-
-# ReConnect flag.
-#
-ReConnect off
-
-# "Local" network.
-#
-#LocalNet 44.139.8.48/32
-
-# Command aliases. See node.conf(5) for the meaning of the uppercase
-# letters in the name of the alias.
-#
-##Alias CAllbook 'telnet %{2:44.17.0.53} 1235 %1 s'
-#Alias CONVers 'telnet %{2:oh2ti} 3600 "/n %u %{1:139}\n/w *"'
-#Alias CLuster 'c hkiclh'
-Alias CONV "telnet lurpac 3600"
-Alias BBS "c 70cm gb7crv"
-Alias DXC "telnet localhost 9000"
-Alias MUD "telnet homer 4000"
-##Alias TEMP "finger temp@mary.g6phf"
-##Alias TNOS "c ip1 gb7mbc-5"
-##Alias TUtor "telnet gb7mbc 3599"
-
-# Hidden ports.
-#
-#HiddenPorts 2
-
-# External commands. See node.conf(5) for the meaning of the uppercase
-# letters in the name of the extcmd.
-#
-# Flags: 1 Run command through pipe
-# 2 Reconnected flag
-#
-#ExtCmd TPM 3 nobody /usr/bin/finger finger tpm
-#ExtCmd ECho 1 nobody /bin/echo echo \%U \%u \%S \%s \%P \%p \%R \%r \%T \%t \%\% \%0 \%{1:foobar} \%{2} \%3 \%4 \%5
-
-# Node ID.
-#
-NodeId "\nBARE:GB7MBC-1"
-#NodeId \033[01;31m***\033[0m
-
-# Netrom port name. This port is used for outgoing netrom connects.
-#
-NrPort netrom
-
-# Logging level
-#
-LogLevel 3
-
-# The escape character (CTRL-T)
-#
-EscapeChar ^T
-
-# Resolve ip numbers to addresses?
-#
-ResolveAddrs off
-
-# Node prompt.
-#
-#NodePrompt "\n"
-#NodePrompt "%s@%h \%i> "
-NodePrompt "\nBARE:GB7MBC-1 \%i > "
-#NodePrompt "\a\033[36m%U\033[0m de \033[01;32m#LNODE\033[0m:\033[01;33mOH2BNS-10\033[0m> "
-</verb></tscreen>
-
-<P>
-This should be fairly obvious I hope.
-
-<sect1>Getting it all running
-
-<P>
-Ok, now we have all the relevant files configured, the next step is to get
-it all running.
-
-<P>
-The first thing to do is attach the TNC's. Your TNC's should be in KISS mode
-and connected to the serial ports involved.
-
-<P>
-You now use the 'kissattach' command to connect the TNC's to the system like this ...
-
-<tscreen><verb>
-kissattach /dev/ttyS0 2m 44.131.96.199
-kissattach /dev/ttyS1 4m 44.131.96.199
-</verb></tscreen>
-
-<P>
-Assuming that 44.131.96.199 is your IP address. The devices ttyS0 and ttyS1 are com1 and
-com2 respectively. Now we can set some parameters ...
-
-<tscreen><verb>
-kissparms -p 2m -t 150 -l 150 -s 50 -r 50
-kissparms -p 4m -t 150 -l 150 -s 50 -r 50
-</verb></tscreen>
-
-<P>
-The command 'man kissparms' will give you the explanation of the switches.
-
-<P>
-Now we need to attach the NET/ROM ports in the same way ...
-
-<tscreen><verb>
-nrattach netrom
-nrattach netrom2
-</verb></tscreen>
-
-<P>
-All of the above can be put in a file and called from /etc/rc.d/rc.local. Put all
-the above commands in a file called rc.ax25 and put a line in rc.local to call it.
-
-<P>
-Now you can start the daemons that set everything in motion ...
-
-<tscreen><verb>
-ax25d
-netromd -i
-</verb></tscreen>
-
-<P>
-All should now be running. All that remains is to get the node working for telnet
-connections. If nothing else, this will allow you to connect to the node yourself
-to check on connection status etc. There are 2 files that need to be edited.
-
-<P>
-First edit /etc/services and add
-
-<tscreen><verb>
-node 3000/tcp #OH2BNS's Node Software
-</verb></tscreen>
-
-<P>
-Assuming you want it to run on port 3000
-
-<P>
-Now cd /etc/xinetd.d and edit a new file called node. It should look like this ...
-
-<tscreen><verb>
-# default: on
-# unencrypted username/password pairs for authentication.
-service node
-{
- socket_type = stream
- wait = no
- user = root
- server = /usr/sbin/node
- log_on_failure += USERID
- disable = no
-}
-</verb></tscreen>
-
-<P>
-You now need to restart the xinetd daemon. First find out what the PID is
-like so ..
-
-<tscreen><verb>
-ps auxw |grep xinetd
-</verb></tscreen>
-
-<P>
-You will get a reply something like this ...
-
-<tscreen><verb>
-root 592 0.0 0.1 2256 620 ? S Feb07 0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
-</verb></tscreen>
-
-<P>
-The PID or Process ID is 592 in this case so now we can issue the command ...
-
-<tscreen><verb>
-kill -HUP 592
-</verb></tscreen>
-
-<P>
-All should now be operational and you should be able to log into the node by
-using a telnet session to the relevant port, like so ...
-
-<tscreen><verb>
-telnet localhost 3000
-</verb></tscreen>
-
-<P>
-If that works, you are just about there. you should (assuming you have radios connected
-to the TNC's) be able to connect out to other stations and receive incoming ax25 and
-netrom connections.
-
-<sect>Configuration
-
-<sect1>Allowing ax25 connects from users
-
-<P>
-This is dealt with in the previous section
-
-<sect1>Allowing telnet connects from users
-
-<P>
->From version 1.47 there is a new (more efficient) way of doing this
-(see next section) but, if you prefer, the method of doing it described
-here will continue to work just fine.
-
-<P>
-Allowing telnet connections is quite simple. Firstly you need to add a line
-in /etc/services to allow connections to a port number, like this ....
-
-<tscreen><verb>
-spdlogin 8000/tcp # spider anonymous login port
-</verb></tscreen>
-
-<P>
-Then add a line in /etc/inetd.conf like this ....
-
-<tscreen><verb>
-spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
-</verb></tscreen>
-
-<P>
-Once this is done, you need to restart inetd like this ....
-
-<tscreen><verb>
-killall -HUP inetd
-</verb></tscreen>
-
-<P>
-Now login as <em>sysop</em> and cd spider/src. You can test that spider
-is accepting telnet logins by issuing the following command ....
-
-<tscreen><verb>
-./client login telnet
-</verb></tscreen>
-
-<P>
-You should get a login prompt and on issuing a callsign, you will be given
-access to the cluster. Note, you will not get a password login. There seems
-no good reason for a password prompt to be given so it is not asked for.
-
-<P>
-Assuming all is well, then try a telnet from your linux console ....
-
-<tscreen><verb>
-telnet localhost 8000
-</verb></tscreen>
-
-<P>
-You should now get the login prompt and be able to login as before.
-
-<sect1>Setting up telnet connects (from 1.47 onwards)
-
-<P>
->From version 1.47 you can choose to allow the perl cluster.pl program to
-allow connections directly (i.e. not via the <tt>/spider/src/client</tt>
-interface program). If you are using Windows then this is the only method
-available of allowing incoming telnet connections.
-
-<P>
-To do this you need first to remove any line that you may previously have set
-up in /etc/inetd.conf. Remember to:-
-
-<tscreen><verb>
-killall -HUP inetd
-</verb></tscreen>
-
-<P>
-to make the change happen...
-
-<P>
-Having done that, you need to copy the file
-<em>/spider/perl/Listeners.pm</em> to <em>/spider/local</em> and
-then edit it. You will need to uncomment the line containing &dquot;0.0.0.0&dquot;
-and select the correct port to listen on. So that it looks like this:-
-
-<tscreen><verb>
-@listen = (
- ["0.0.0.0", 8000],
-);
-</verb></tscreen>
-
-<P>
-As standard, the listener will listen on all interfaces simultaneously.
-If you require more control than this, you can specify each interface
-individually:-
-
-<tscreen><verb>
-@listen = (
- ["gb7baa.dxcluster.net", 8000],
- ["44.131.16.2", 6300],
-);
-</verb></tscreen>
-
-<P>
-This will only be successful if the IP addresses on each interface are static.
-If you are using some kind of dynamic IP addressing then the 'default' method
-is the only one that will work.
-
-<P>
-Restart the cluster.pl program to enable the listener.
-
-<P>
-One important difference with the internal listener is that no echoing
-is done by the cluster program. Users will need to set 'local-echo' on in
-their telnet clients if it isn't set automatically (as per the standards).
-Needless to say this will probably only apply to Windows users.
-
-<sect1>Setting up for AGW Engine (1.47 onwards)
-
-<P>
-AGW Engine is a Windows based ax25 stack. You can connect to an AGW engine
-from Linux as well as Windows based machines.
-
-<P>
-In order to enable access to an AGW Engine you need to copy
-<em>/spider/perl/AGWConnect.pm</em> to <em>/spider/local</em> and edit it.
-Specifically you must:-
-
-<itemize>
-<item> set <tt>$enable</tt> to 1.
-<item> set <tt>$login</tt> and <tt>$passwd</tt> to the values set up in your AGW installation.
-If you haven't set any there, then you should not touch these values.
-<item> You can connect to a remote AGW engine (ie on some other machine) by changing <tt>$addr</tt>
-and <tt>$port</tt> appropriately.
-<item> Restart the cluster.pl program
-</itemize>
-
-
-<sect1>Setting up node connects
-
-<P>
-In order to allow cluster node connections, spider needs to know that the
-connecting callsign is a cluster node. This is the case whether the connect
-is incoming or outgoing. In spider this is a simple task and can be done in
-runtime.
-
-<P>
-Later versions of Spider can distinguish different software and treat them
-differently. For example, the WCY beacon cannot be handles by AK1A type
-nodes as AK1A does not know what to do with PC73. There are 4 different
-types of node at present and although they may not have any major
-differences at the moment, it allows for compatibility. The 4 types are ...
-
-<tscreen><verb>
-set/node (AK1A type)
-set/spider
-set/dxnet
-set/clx
-</verb></tscreen>
-
-<P>
-For now, we will assume that the cluster we are going to connect to is an
-AK1A type node.
-
-<P>
-Start up the cluster as you did before and login as the sysop with client.
-The cluster node I am wanting to make a connection to is GB7BAA but you would
-obviously use whatever callsign you required. At the prompt type ...
-
-<tscreen><verb>
-set/node gb7baa
-</verb></tscreen>
-
-<P>
-The case does not matter as long as you have a version of DXSpider later than
-1.33. Earlier versions required the callsign to be in upper case.
-
-<P>
-That is now set, it is as simple as that. To prove it, login on yet another
-console as sysop, cd to spider/src and issue the command ...
-
-<tscreen><verb>
-./client gb7baa (using the callsign you set as a node)
-</verb></tscreen>
-
-<P>
-You should get an initialisation string from DXSpider like this ...
-
-<tscreen><verb>
-./client gb7baa
-PC38^GB7MBC^~
-</verb></tscreen>
-
-If the callsign you just set up as a cluster node is for an incoming connect,
-this is all that needs to be done. If the connection is to be outgoing then
-a connection script needs to be written.
-
-<P>
-Sometimes you make a mistake... Honest, it does happen. If you want to make a node
-back to being a normal user, regardless
-of what type it is, do:
-
-<tscreen><verb>
-unset/node gb7baa
-</verb></tscreen>
-
-<sect1>Connection scripts
-
-<P>
-Because DXSpider operates under Linux, connections can be made using just about
-any protocol; AX25, NETRom, tcp/ip, ROSE etc are all possible examples.
-Connect scripts live in the /spider/connect directory and are simple ascii files.
-Writing a script for connections is therefore relatively simple.
-
-<P>
-The connect scripts consist of lines which start with the following keywords
-or symbols:-
-
-<descrip>
-
-<tag/#/All lines starting with a <tt>#</tt> are ignored, as are completely
- blank lines.
-
-<tag/timeout/<tt>timeout</tt> followed by a number is the number of seconds to wait for a
- command to complete. If there is no timeout specified in the script
- then the default is 60 seconds.
-
-<tag/abort/ <tt>abort</tt> is a regular expression containing one or more strings to look
- for to abort a connection. This is a perl regular expression and is
- executed ignoring case.
-
-<tag/connect/<tt>connect</tt> followed by ax25, agw (for Windows users) or telnet and some type dependent
- information. In the case of a telnet connection, there can be up to
- two parameters.
- The first is the ip address or hostname of the computer you wish to
- connect to and the second is the port number you want to use (this
- can be left out if it is a normal telnet session).
- In the case of an ax25 session then this would normally be a call to
- ax25_call or netrom_call as in the example above. It is your
- responsibility to get your node and other ax25 parameters to work
- before going down this route!
-
-<tag/'/<tt>'</tt> is the delimiting character for a word or phrase of an expect/send
- line in a chat type script. The words/phrases normally come in pairs,
- either can be empty. Each line reads input from the connection until
- it sees the string (or perl regular expression) contained in the
- left hand string. If the left hand string is empty then it doesn't
- read or wait for anything. The comparison is done ignoring case.
- When the left hand string has found what it is looking for (if it is)
- then the right hand string is sent to the connection.
- This process is repeated for every line of chat script.
-
-<tag/client/<tt>client</tt> starts the connection, put the arguments you would want here
- if you were starting the client program manually. You only need this
- if the script has a different name to the callsign you are trying to
- connect to (i.e. you have a script called other which actually
- connects to GB7DJK-1 [instead of a script called gb7djk-1]).
-</descrip>
-
-<P>
-There are many possible ways to configure the script but here are three examples,
-one for a NETRom/AX25 connect, one for AGW engines and one for tcp/ip.
-
-<tscreen><verb>
-timeout 60
-abort (Busy|Sorry|Fail)
-# don't forget to chmod 4775 netrom_call!
-connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh
-'Connect' ''
-'Connect' 'c np7'
-'Connect' 'c gb7dxm'
-# you can leave this out if you call the script 'gb7dxm'
-client gb7dxm ax25
-</verb></tscreen>
-
-<P>
-
-<tscreen><verb>
-timeout 60
-abort (Busy|Sorry|Fail)
-# this does exactly the same as the previous example
-# the '1' is the AGW port number to connect thru for g1tlh
-connect agw 1 g1tlh
-'Connect' ''
-'Connect' 'c np7'
-'Connect' 'c gb7dxm'
-# you can leave this out if you call the script 'gb7dxm'
-client gb7dxm ax25
-</verb></tscreen>
-
-<P>
-
-<tscreen><verb>
-timeout 15
-connect telnet dirkl.tobit.co.uk
-'login' 'gb7djk'
-'word' 'gb7djk'
-# tell GB7DJK-1 that it is connected to GB7DJK
-# you can leave this out if you call this script 'gb7djk'
-client gb7djk telnet
-</verb></tscreen>
-
-<P>
-Both these examples assume that everything is set up properly at the other end.
-You will find other examples in the /spider/examples directory.
-
-<sect1>Starting the connection
-
-<P>
-You start the connection, from within a sysop enabled cluster login, by typing
-in the word <em>connect</em> followed by a script name like this ....
-
-<tscreen><verb>
-G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
-connection to GB7DJK-1 started
-G0VGS de GB7MBC 13-Dec-1998 2043Z >
-</verb></tscreen>
-
-<P>
-This will start a connection using the script called <em>gb7djk-1</em>. You can
-follow the connection by watching the term or console from where you started
-<em>cluster.pl</em>. From version 1.47 onwards, you will need to <tt>set/debug connect</tt> first.
-You should see something like this ...
-
-<tscreen><verb>
-<- D G1TLH connect gb7djk-1
--> D G1TLH connection to GB7DJK-1 started
--> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
-timeout set to 15
-CONNECT sort: telnet command: dirkl.tobit.co.uk
-CHAT "login" -> "gb7djk"
-received "
-Red Hat Linux release 5.1 (Manhattan)
-Kernel 2.0.35 on an i586
-"
-received "login: "
-sent "gb7djk"
-CHAT "word" -> "gb7djk"
-received "gb7djk"
-received "Password: "
-sent "gb7djk"
-Connected to GB7DJK-1, starting normal protocol
-<- O GB7DJK-1 telnet
--> B GB7DJK-1 0
-GB7DJK-1 channel func state 0 -> init
-<- D GB7DJK-1
-<- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
-<- D GB7DJK-1 PC38^GB7DJK-1^~
-<- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime
-0 00:00^5447^~
- etc
-
-</verb></tscreen>
-
-<P>
-With later versions of Spider there is a set/login command for users. This
-tells them when a user or node logs in or out. If you do not add a line to
-your scripts after the final line (or before the client line which should always
-be last if needed) then the login/logout information will be sent to users
-<it>before</it> the login actually completes. This means if a node is
-unreachable, it will continue sending logins and logouts to users even though it
-is not actually connecting. To avoid this use the following line ...
-
-<tscreen><verb>
-'connect' ''
-</verb></tscreen>
-
-<P>
-In a script, this might look like ...
-
-<tscreen><verb>
-timeout 35
-abort (Busy|Sorry|Fail)
-connect telnet mary 3000
-'ogin:' 'gb7mbc'
-'>' 'telnet 44.131.93.96 7305'
-'connect' ''
-</verb></tscreen>
-
-<sect1>Telnet echo
-
-<P>
-Cluster links in particular suffer greatly from the presence of telnet echo.
-This is caused by the telnet negotiation itself and can create at worst severe
-loops. At best it creates unnecessary bandwidth and large logfiles! There are
-things that can be done to limit this problem but will not always work dependent
-on the route taken to connect.
-
-<P>
-Telnet echo itself should only be a problem if the connection is being made to
-the telnet port (23). This port uses special rules that include echo negotiation.
-If the connection is to a different port, such as 7300, this negotiation does
-not happen and therefore no echo should be present.
-
-<P>
-Sometimes it is not possible to make a direct connection to another node and this
-can cause problems. There is a way of trying to suppress the telnet echo but
-this will not always work, unfortunately it is difficult to be more specific.
-Here is an example of what I mean ...
-
-<tscreen><verb>
-timeout 35
-abort (Busy|Sorry|Fail)
-connect telnet mary.lancs.ac.uk
-'ogin:' 'gb7mbc'
-'word:' 'mypasswd'
-'\$' 'stty -echo raw'
-'\$' 'telnet 44.131.93.96'
-'connect' ''
-</verb></tscreen>
-
-<P>
-So, the first connection is made by Spider. This is fine as Spider uses the
-Net_Telnet script from within perl. This actually uses TCP rather than TELNET
-so no negotiation will be done on the first connection. Once connected to
-mary.lancs.ac.uk, the command is sent to suppress echo. Now a telnet is made
-to a cluster node that is accepting connections on port 23. The problem with
-this link is that the negotiation is made by the remote machine, therefore you
-have no control over it. The chances are that this link will create echo and
-there will be no way you can stop it.
-
-
-<sect1>Autostarting the cluster
-
-<P>
-Ok, you should now have DXSpider running nicely and allowing connects by cluster
-nodes or users. However, it has to be shutdown and restarted manually. It
-would be much easier to have it start automatically.
-
-<P>
-This is not only a way to start the cluster automatically, it also works as a
-watchdog, checking the sanity of DXSpider and respawning it should it crash for
-any reason. Before doing the following, shutdown the cluster as you did earlier.
-
-<P>
-Login as root and bring up the /etc/inittab file in your favourite editor. Add
-the following lines to the file near the end ...
-
-<tscreen><verb>
-##Start DXSpider on bootup and respawn it should it crash
-DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
-</verb></tscreen>
-
-<P>
-This line works fine for RedHat distributions. It is also fine for SuSE up to
-7.0. From SuSE 7.1 you need to add runlevels 2 and 5 like this ...
-
-<tscreen><verb>
-DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
-</verb></tscreen>
-
-<P>
-The line required for Slackware distributions is slightly different. My thanks to
-Aurelio, PA3EZL for this information.
-
-<tscreen><verb>
-DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
-</verb></tscreen>
-
-<P>
-This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart
-it should it crash for any reason.
-
-<P>
-NB: It should be noted that /dev/tty7 is only an example. Some SuSE systems will
-only accept upto tty6. It really does not matter which tty you run it on.
-
-<P>
-As root type the command <em>telinit q</em>. DXSpider should start up
-immediately. You will see the output on tty7 and if you login as <em>sysop</em>
-you should find everything running nicely.
-
-<sect>Microsoft Windows Installation
-
-<sect1>Introduction
-
-<P>
-<bf>IMPORTANT:</bf>
-
-What you'll be left with once you've followed these instructions
-is (hopefully) a working DX Spider v1.50 system that is capable
-of accepting or originating "internet" connections, plus inbound
-and outbound AX.25 and TCP/IP radio connections.
-
-On the other hand, you may have an enquiring mind, or better yet,
-may be looking for a useful way of connecting your current
-(perhaps) AK1A cluster "to the internet" via some networking
-mechanism (BPQEther, etc) or other. I won't be producing
-instructions for the latter case, because I don't have an AK1A to
-play with. But someone might ...
-
-Whatever, this document is intended to get you started with DX
-Spider in a Microsoft Windows ™ environment. It's not
-intended to teach you anything other than how to perform a
-minimum configuration of a DX Spider installation and have it
-able to connect across "the internet" to other DX Clusters, while
-accepting inbound TELNET and radio connections.
-
-<sect1>The requirements
-
-<P>
-The very first things you're going to need are (in order of
-importance):-
-
-<itemize>
-<item>A cup of good, strong tea
-<item>A supported Windows platform with an internet connection so you can
-download the necessary software bits and bobs directly to it. There are other ways, but this is preferable.
-<item>Another cup of good, strong tea
-<item>If all goes according to plan, about an hour to spare
-<item>Plenty of good, strong tea
-</itemize>
-
-<sect1>The system
-
-<P>
-The platform I used to generate these instructions was a
-"vanilla" Microsoft Windows Me 4.90.3000 system, with a 700MHz
-AMD Athlon processor and 96 Mb memory. I've also personally
-verified that it runs on my laptop (Pentium 266MHz, 32 Mb memory,
-Windows 98 SE v4.10.2222 A) and a computer that I assembled from
-a random pile of junk (AMD K6-2 333MHz, 64 Mb memory, Windows 98
-v4.10.1998). As a result, I have reason to believe that what I'm
-about to describe will perform equally on any 32-bit MS Windows
-environment with 32 Mb of memory.
-
-Because of the changes that have recently been made to the core
-"cluster.pl" module and the introduction of a very lightweight
-"winclient.pl", I have a sneaking suspicion that this will now
-run on any platform that has reasonably complete support for
-Perl. Is there someone out there with both an enquiring mind and
-(say) a Macintosh, for instance?
-
-Please bear in mind, though, that my instructions relate solely
-to how to get this going under a Microsoft Windows environment,
-and I have zero intention of trying to make them say otherwise.
-
-<sect1>Perl
-
-<P>
-Install your chosen Perl environment. Unless you have a very good
-reason for not doing so, I strongly suggest that you use
-ActivePerl v5.6. For my testing & development, I used build 623.
-(A recent installation used the newer ActivePerl v5.6.1, build
-633 without any noticable difficulty.) You can get this from:
-<htmlurl url="http://www.activestate.com/Products/ActivePerl/Download.html"
-name="http://www.activestate.com/Products/ActivePerl/Download.html">
-
-The link takes you to an initial page of System Requirements and
-Software Prerequisites. If you do not have it already installed,
-you can download and install the Windows Installer 2.0 for a Win98
-installation. Be forewarned, you will have to reboot your PC at the
-completion of the installer's installation.
-
-If you already have the installer on your PC, simply click on the
-Next arrow at the bottom of the page. Two clicks will finally get
-you to the actual download page. The MSI version of Build 633 is
-now 8.6MB in size, so make that a big cup of tea or coffee if you're
-on a slow dial-up connection.
-
-During installation, please ensure that you do choose the options
-to "Add Perl to the PATH environment variable" and "Create Perl
-file extension association"; it will make your life so much
-easier. Once the installation is finished, be sure to reboot your
-PC. You probably won't be told anywhere else that this needs to
-be done now, but it does. Really.
-
-Once you've rebooted, open a "DOS box" (Start > Run > command
-might do it, if you can't find it elsewhere) and from wherever it
-lands, type PERL -v <ENTER> (it's better if that's a lower-case
-'v', because an upper-case 'V' means something else. You should
-be rewarded with some interesting information about your Perl
-installation. If you're not, you must go back to the beginning
-and discover what went wrong and fix it. It's pointless to
-proceed unless this simple check is passed. Assuming it did work,
-you may now move on.
-
-<sect1>Additional packages
-
-<P>
-Some extensions ("packages") need to be added to the base Perl
-distribution, and we'll do this next. If you're using the Perl I
-recommended, and don't know any better for yourself, then just
-blindly following these instructions will work just fine. If that
-didn't describe you, then you're on your own.
-
-Visit the following URL:
-
-<htmlurl url="http://www.activestate.com/PPMPackages/zips/6xx-builds-only/"
-name="http://www.activestate.com/PPMPackages/zips/6xx-builds-only/">
-
-and download the following files:-
-
-<tscreen><verb>
-Data-Dumper.zip
-Net-Telnet.zip
-TimeDate.zip
-Time-HiRes.zip
-DB_File.zip
-</verb></tscreen>
-
-If this is a new installation, now would also be a good time to
-install a copy of WinZip on your PC. Make yourself a convenient
-directory to unpack all of these zip files into (I put mine in
-"D:\ppm>" but "C:\ppm" works just as well.) and do the following
-(the bits you type in are blue ). You can upzip all of the files into
-the same directory. When prompted, simply overwrite the Readme file
-from each zip package. Note that where these files land will be
-directly related to where you chose to install your ActivePerl
-(mine, as you can probably guess from what follows, went into "D:\Perl"):-
-
-<tscreen><verb>
-D:\ppm>ppm install Data-Dumper.ppd
-Installing package 'Data-Dumper.ppd'
-Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.bs
-Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.dll
-Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.exp
-Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.lib
-Installing D:\Perl\html\site\lib\auto\Data\Dumper\Dumper.html
-Installing D:\Perl\site\lib\Data\Dumper\Dumper.pm
-Writing D:\Perl\site\lib\auto\Data\Dumper\Dumper.packlist
-D:\ppm>
-</verb></tscreen>
-
-I'm not going to bother you with exhaustive details of the rest
-of them, but suffice it to say you need to:
-
-<tscreen><verb>
-ppm install DB_File.ppd
-ppm install Net-Telnet.ppd
-ppm install TimeDate.ppd
-ppm install Time-HiRes.ppd
-</verb></tscreen>
-
-If all that seemed to work OK, time to move along. Before anyone
-who is familiar with PPM tells me that we didn't need to download
-and keep those files locally, I knew that. I also knew that PPM
-is sometimes awkward to configure via firewalls, and that
-sometimes the repositories don't always work the way we'd hope. I
-do it that way because it suits me.
-
-<sect1>Getting Spider
-
-<P>
-Get the current version of the DX Spider distribution. This needs
-to be v1.50 or later. You've got two ways (currently) of getting
-this; either get a CVS update from sourceforge (if you don't know
-what this is, then it isn't for you) or get the latest "official"
-release from:
-
-<htmlurl url="http://www.dxcluster.org/download/index.html" name="http://www.dxcluster.org/download/index.html">
-
-or if you want the lastest snapshot of CVS version (which is produced
-every night):-
-
-<htmlurl url="http://www.dxcluster.org/download/CVSlatest.tgz" name="http://www.dxcluster.org/download/CVSlatest.tgz">
-
-This is generally the best one to go for as it is completely up to
-date. However, there is always the very slight chance that it might
-unstable. Generally, there will be a note on the website if this is
-the case.
-
-
-The only difference between "CVSlatest.tgz" and the latest
-"official" release version is that it is more up to date. <bf>Do not confuse
-the "CVSlatest.tgz" file with "Downloading from Sourceforge with CVS" - they
-are two quite different things.</bf> "Downloading from Sourceforge with CVS" is
-explained in a section within the Admin manual.
-
-<p>
-If you go down the CVS route (ie installing WinCVS as explained in the Admin
-manual and downloaded from sourceforge), then everything will be nicely
-installed on your local disk. If you got the CVSlatest.tgz file, unzip
-(<htmlurl url="http://www.winzip.com" name="winzip">) it to "C:\".
-This is an important point since paths are included within the .tgz
-file. Make sure you unzip to the root directory of whichever drive you use...
-"C:\" or "D:\" or .., not "C:\spider." If you double click on CVSlatest.tgz,
-WinZip should open with a dialogue box that says the Archive contains a single
-file (CVSlatest.tar) and asks whether WinZip should decompress it to a
-temporary fold and then open it. Say "Yes" and then you will get the typical
-Classical WinZip listing of files ready for extraction. Remember, extract
-them to your desired root directory ("C:\" or "D:\" or ...). The following
-examples assume that you put it on drive "C:\", for convenience.
-
-<sect>Installing the software
-
-<P>
-At this point you will need to create 2 additional directories under
-"C:\Spider." Make directories "C:\spider\local" and "C:\spider\local_cmd".
-If "C:\spider" is missing, go back and figure out why, because it shouldn't be.
-
-Now create your own local copy of the DXVars.pm file by:-
-
-<tscreen><verb>
-copy c:\spider\perl\DXVars.pm.issue
-c:\spider\local\DXVars.pm
-</verb></tscreen>
-
-Now you'll need to edit this file using a text editor like Notepad. If nothing
-else, you can simply
-
-<tscreen><verb>
-cd \spider\local
-</verb></tscreen>
-
-and then
-
-<tscreen><verb>
-notepad DXVars.pm
-</verb></tscreen>
-
-to bring up an editor window containing the file. As an absolute
-minimum you must adjust the following items in DXVars.pm:-
-
-<itemize>
-<item> $mycall - Should hold the callsign of your DX Cluster
-<item> $myname - The SysOp's first name
-<item> $myalias - the SysOp's callsign. Cannot be the same as $mycall!
-<item> $myqth - The station's geographical location (QTH).
-<item> $mylatitude - The station latitude in degrees and decimal fractions
-<item> $mylongitude - The station longitude in degrees and decimal fractions
-<item> $mylocator - The Maidenhead (or QRA) locator of the station
-</itemize>
-
-You really also ought to update the $myqth and $myemail variables. And
-unless you are absolutely certain you know what you're doing, you
-should change nothing else in this file. Note that if you use an "@" or
-a "$" character in one of the above strings (typically in $myemail) you must
-write them as "\@" or "\$".
-
-<sect1>Incoming telnets
-
-<P>
-If you want to enable inbound "TELNET" connections (or you are running
-Windows 98, NT, 2000 or XP), you've got a little more work to do. From a
-handy "DOS box" that's not doing anything else, do the following:-
-
-<tscreen><verb>
-copy \spider\perl\Listeners.pm \spider\local
-cd \spider\local
-notepad listeners.pm
-</verb></tscreen>
-
-The following line need attention:-
-
-<tscreen><verb>
-# ["0.0.0.0", 7300],
-</verb></tscreen>
-
-On my machine, I've simply uncommented the "0.0.0.0" entry by
-removing the '#' from the front of the line.
-
-<bf>You MUST carry out this step if you are
-running on a Windows 98, NT, 2000 or XP based system</bf>
-
-If you don't have a static hostname for your machine, and you
-intend to allow folk to connect to your machine across the
-internet, then I'd suggest you pay a visit to www.dyndns.org and
-create one for yourself. While it's free, it will take a modest
-amount of effort on your part to read, understand and
-implement what needs to be done to set this up.
-
-<p>If your machine is connected to the internet <bf>and</bf> you don't
-want to allow your machine to be visible to the outside world you
-should change the "0.0.0.0" to "127.0.0.1" [which is
-"localhost"]. This will then only allow connections from inside your
-machine. As was said earlier: if you aren't running Win9x (or you want
-to use DXTelnet or somesuch), then you need to have the machine
-listening at least to "127.0.0.1" ("0.0.0.0" means <bf>all</bf> IP
-addresses).
-
-<sect1>The AGW packet engine
-
-<P>
-On the assumption that you'll be using the SV2AGW Packet Engine
-to interface your radios to the cluster, it would be a good idea to
-download the Packet Engine software! You can get this software from:
-
-<htmlurl url="http://www.raag.org/sv2agw/agwpe.zip" name="http://www.raag.org/sv2agw/agwpe.zip">
-
-Depending upon your TNCs, you may also need to get:
-
-<htmlurl url="http://www.raag.org/sv2agw/drivers.zip" name="http://www.raag.org/sv2agw/drivers.zip">
-
-A couple of the tools:
-
-<htmlurl url="http://www.raag.org/sv2agw/agwterm.zip" name="http://www.raag.org/sv2agw/agwterm.zip">
-
-<htmlurl url="http://www.raag.org/sv2agw/agwmonitor.zip" name="http://www.raag.org/sv2agw/agwmonitor.zip">
-
-will also help with troubleshooting of the RF links themselves.
-
-Install and configure AGWPE. You should now create your own local copy of
-AGWConnect.pm by:-
-
-<tscreen><verb>
-copy c:\spider\perl\AGWConnect.pm
-c:\spider\local\AGWConnect.pm
-</verb></tscreen>
-
-and then
-
-<tscreen><verb>
-notepad AGWConnect.pm
-</verb></tscreen>
-
-to bring up an editor window containing the file. You must
-consider adjusting the following items in AGWConnect.pm:-
-
-<itemize>
-<item>$enable - set to '1' to enable AGWPE interface
-<item>$login - the login ID you chose when you set up the SV2AGW security :-)
-<item>$passwd - password that matches $login
-</itemize>
-
-The login ID and passwd only need to be set if you are accessing AGW separately
-via its web interface. This interface is normally not needed for use with DXSpider.
-
-<sect1>Setting up the initial user files
-
-<P>
-Next you need to create the initial user files, etc. A tool is
-supplied which will do this for you. To run the tool:-
-
-<tscreen><verb>
-cd \spider\perl
-perl create_sysop.pl
-</verb></tscreen>
-
-If all goes according to plan, you will see no output from this
-program, and after a brief wait, your DOS prompt will be
-returned.
-
-Depending on how brave you are, you might now care to try the
-following:-
-
-<tscreen><verb>
-perl cluster.pl
-</verb></tscreen>
-
-If you did everything you were told, your DOS window will now
-hold a display which looks something like:-
-
-<tscreen><verb>
-DXSpider DX Cluster Version 1.50
-Copyright (c) 1998-2002 Dirk Koopman G1TLH
-loading prefixes ...
-loading band data ...
-loading user file system ...
-starting listeners ...
-Internal port: localhost 27754
-load badwords: Ok
-reading in duplicate spot and WWV info ...
-reading existing message headers ...
-load badmsg: Ok
-load forward: Ok
-load swop: Ok
-@msg = 0 before delete
-@msg = 0 after delete
-reading cron jobs ...v cron: reading /spider/cmd/crontab
-cron: adding 1 0 * * 0
-DXUser::export("$main::data/user_asc")
-reading database descriptors ...
-doing local initialisation ...
-orft we jolly well go ...
-queue msg (0)
-</verb></tscreen>
-
-Now, if that's what you've got, you are very nearly home and dry
-(in as far as these particular experiments are concerned, anyhow)
-
-If you are running Windows 9x you can access your new cluster (from
-the local machine) by finding yourself another "DOS box" and doing the
-following:-
-
-<tscreen><verb>
-cd \spider\perl
-perl winclient.pl
-</verb></tscreen>
-
-If you are running Windows NT, 2000 or XP then winclient.pl does not
-work. We don't know why other than this seems to be some kind of
-incomaptibility in perl. You can achieve the same thing by telnetting
-to the port you defined in Listeners.pm (7300 as default), thus:-
-
-<tscreen><verb>
-Menu->Start->Run
-telnet localhost 7300
-</verb></tscreen>
-
-On getting the <bf>login:</bf> prompt, enter your sysop callsign (the one you
-put in DXVars.pm as $myalias).
-
-<p>I would recommend <bf>strongly</bf> that you obtain a better telnet
-client than that which comes with windows (I use <htmlurl
-url="http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html"
-name="PuTTY">).
-
-<p>Anyway, if you are rewarded with a display which looks something like:-
-
-<tscreen><verb>
-Hello Iain, this is GB7SJP in Amersham, Bucks running DXSpider V1.50
-Cluster: 1 nodes, 1 local / 1 total users Max users 2 Uptime 0 00:00
-M0ADI de GB7SJP 4-Mar-2001 1511Z >
-</verb></tscreen>
-
-You've arrived. Try some commands, and see how they feel. (In
-case you were wondering, "Iain", "M0ADI" and "GB7SJP" all came
-from the version of DXVars.pm that was on the machine when I
-started the winclient.pl)
-
-<p>The interface is very basic. It is a simple command line. There are
-better looking interfaces. Most of the "standard" logging and DX
-Cluster access programs that are capable of connecting via a TCP or
-telnet connection will work as a "Sysop Console" client. You connect
-to "localhost" on the port that you defined in Listeners.pm (usually
-7300). I recommend packages like <htmlurl
-url="http://www.qsl.net/wd4ngb/telnet.htm" name="DXTelnet">.
-
-<sect1>Connecting to other clusters
-
-<P>
-If you want to connect this to another cluster, then you'll want to
-negotiate a link with someone. For experimental purposes, I'm happy to
-allow folk to connect to GB7DXA (spud.ath.cx), on the understanding
-that the system may or may not be there and may or may not be
-connected to anything particularly useful at any given moment. Contact
-me by <htmlurl url="mailto:g0rdi@blacksheep.org" name="Email"> if you
-want me to set up a connection for you.
-
-<sect>General Information
-
-<P>
-The following relates to all versions of DXSpider and is not platform related.
-
-<sect1>The crontab file
-
-<P>
-Login as <em>sysop</em> and create a file in /spider/local_cmd called crontab.
-Edit it with your favourite editor and add a line like this (I have included
-a comment)
-
-<tscreen><verb>
-# check every 10 minutes to see if gb7xxx is connected and if not
-# start a connect job going
-
-0,10,20,30,40,50 * * * * start_connect('gb7xxx') unless connected('gb7xxx')
-</verb></tscreen>
-
-<P>
-The callsign involved will be the callsign of the cluster node you are
-going to connect to. This will now check every 10 minutes to see if
-gb7xxx is connected, if it is then nothing will be done. If it is not,
-then a connect attempt will be started.
-
-<P>
-There are probably lots of other things you could use this crontab file for.
-If you want to know more about it, look at the
-<htmlurl url="http://www.dxcluster.org/cron.html" name="DXSpider"> website
-at the cron page where it is explained more fully.
-
-</article>
-
-
projects / spider.git / blobdiff