<!-- Title information -->
-<title>The DXSpider Installation and Administration Manual</title>
-<author>Ian Maude, G0VGS, (ianmaude@btinternet.com)</author>
-<date>$Date$ $Revision$</date>
-<abstract>
-A reference for SysOps of the DXSpider DXCluster program.
-</abstract>
-
-<!-- Table of contents -->
-<toc>
-
-<!-- Begin the document -->
-
-<sect>Installation (Original version by Iain Philipps, G0RDI)
-
-<sect1>Introduction
-
-<P>
-This section describes the installation of DX Spider v1.46 on a
-<htmlurl url="http://www.redhat.com" name="RedHat"> Linux Distribution.
-Wherever possible I will try to include differences for other distributions.
-I do not intend to try and cover the installation of Linux or the setup
-of the AX25 utilities. If you need help on this then read Iains original
-installation guide that comes with the Spider distribution.
-
-<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/CPAN.html" name="http://www.cpan.org/CPAN.html"> ...
-
-<P>
-<itemize>
-
-<item> Data-Dumper-2.101.tar.gz
-<item> TimeDate-1.10.tar.gz
-<item> IO-1.20.tar.gz (for perl 5.00403 and lower)
-<item> Net-Telnet-3.02.tar.gz
-<item> Curses-1.05.tar.gz
-<item> Time-HiRes-01.20.tar.gz
-
-</itemize>
-
-<P>
-
-<em>Do</em> get the latest versions of these packages and install them
-but use the above list as the earliest versions usable.
-
-<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.46 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.
-
-<P>
-<tscreen><verb>
-# adduser -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.46.tar.gz
-# ln -s ~sysop/spider /spider
-# groupadd -g 251 spider (or another number)
-</verb></tscreen>
-
-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>
-
-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. 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><bf>PLEASE USE CAPITAL LETTERS FOR CALLSIGNS</bf>
-
-<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>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.46
-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>
-
-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.
-
-<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.
-
-
-<sect>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>
-
-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>
-
-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>Configuration
-
-<sect1>Allowing ax25 connects from users
-
-<P>
-As stated previously, the aim of this document is not to tell you how to
-configure Linux or the ax25 utilities. However, you do need to add a line
-in your ax25d.conf to allow connections to DXSpider for your users. For
-each interface that you wish to allow connections on, use the following format ...
-
-<tscreen><verb>
-default * * * * * * - sysop /spider/src/client client %u ax25
-</verb></tscreen>
-
-or, 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>
-
-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
-owuld 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>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 7300/tcp # spider anonymous login port
-</verb></tscreen>
-
-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>
-
-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 7300
-</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 chose to allow the perl cluster.pl program to
-allow connections direct (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 then you need to copy the file
-<tt>/spider/perl/Listeners.pm</tt> to <tt>/spider/local</tt> 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", 7300],
-);
-</verb></tscreen>
-
-<p>As standard, the listener will listen on all interfaces simultaniously. If you require more
-control than this, you can specify each interface individually:-
-
-<tscreen><verb>
-@listen = (
- ["gb7baa.dxcluster.net", 7300],
- ["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 which 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 <tt>/spider/perl/AGWConnect.pm</tt>
-to <tt>/spider/local</tt> 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>
-
-
-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>
-
-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>
-
-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.
-
-
-<sect>Automating things
-
-<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 and if
-connection scripts fail they have to be started again manually too, not much use
-if you are not at the console! So, in this section we will automate both.
-Firstly starting the cluster.
-
-<sect1>Autostarting the cluster
-
-<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>
-
-
-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>
+<title>The DXSpider Administration Manual v1.49</title>
+<author>Ian Maude, G0VGS, (g0vgs@gb7mbc.net)</author>
+<date>February 2002 revision 1.3</date>
-<P>
-This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart
-it should it crash for any reason.
-
-<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.
-
-<P>
-So far so good, now to automate script connections...
-
-<sect1>The crontab file
+<abstract>
+A reference for SysOps of the DXSpider DXCluster program.
+</abstract>
-<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)
+<!-- Table of contents -->
+<toc>
-<tscreen><verb>
-# check every 10 minutes to see if gb7xxx is connected and if not
-# start a connect job going
+<!-- Begin the document -->
-0,10,20,30,40,50 * * * * start_connect('gb7xxx') if unless connected('gb7xxx')
-</verb></tscreen>
+<sect>Routing and Filtering
-<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.
+<sect1>Introduction
<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.
-
-<sect>Hop control
+From DXSpider version 1.48, major changes were introduced to the way
+node connections are treated. This is part of an ongoing process to
+remove problems with loops and to enable talk and other functions to
+propagate across the whole of the worldwide cluster network. In fact,
+in a Spider network, it would be useful, perhaps even necessary to
+have loops. This would give real resilience to the network, meaning
+that if a link dropped, the information flow would simply come in and
+go out via a different route. Of course, we do not have a complete
+network of Spider nodes, there are other programs out there. Some of
+these do not have any protection from loops. Certainly AK1A does not
+handle loops well at all. It is therefore necessary to have some form
+of protection for these nodes.
<P>
-Starting with version 1.13 there is simple hop control available on a per
-node basis. Also it is possible to isolate a network completely so that you
-get all the benefits of being on that network, but can't pass on information
-from it to any other networks you may be connected to (or vice versa).
-
-<sect1>Basic hop control
+In fact DXSpider has had a simple system for some time which is called
+<it>isolation</it>. This is similar to what in other systems such as
+<bf>clx</bf>, is called <it>passive mode</it>. A more detailed explanation
+of <it>isolation</it> is given further below. This system is still available
+and, for simple networks, is probably all that you need.
<P>
-In /spider/data you will find a file called hop_table.pl. This is the file
-that controls your hop count settings. It has a set of default hops on the
-various PC frames and also a set for each node you want to alter the hops for.
-You may be happy with the default settings of course, but this powerful tool
-can help to protect and improve the network. The file will look something
-like this ...
-
-<tscreen><verb>
-#
-# hop table construction
-#
+The new functionality introduced in version 1.48 allows filtering the node
+and user protocol frames on a "per interface" basis. We call this
+<it>route filtering</it>. This is used <bf>instead of</bf>
+<it>isolation</it>.
-package DXProt;
+<p>
+What this really means is that you can control more or less completely
+which user and node management PC protocol frames pass to each of your
+partner nodes. You can also limit what comes into your node from your
+partners. It is even possible to control the settings that your partner
+node has for the routing information that it sends to you
+(using the <it>rcmd</it> command).
-# default hopcount to use
-$def_hopcount = 5;
+<sect1>Route Filters
-# some variable hop counts based on message type
-%hopcount =
-(
- 11 => 10,
- 16 => 10,
- 17 => 10,
- 19 => 10,
- 21 => 10,
-);
+<p>
+Initially when route filters were being tested we generated a
+"default" filter. Unfortunately it quickly became apparent that this
+might suit the UK cluster network but didn't really fit anybody else.
+However using a default filter is an appropriate thing to do. How, is
+explained further on.
+<p>
+The first thing that you must do is determine whether you need to use
+route filtering <bf>at all</bf>. If you are a "normal" node with two or
+three partners and you arranged in an "official" non-looping tree type
+network, then <bf>you do not need to do route filtering</bf> and you will
+feel a lot better for not getting involved. If you are successfully using
+<it>isolation</it> then you also probably don't need to use route filtering.
-# the per node hop control thingy
+<p>
+To put it simply, you should not mix Isolation and Route Filtering. It
+will work, of sorts, but you will not get the expected results. If you
+are using Isolation sucessfully at the moment, do not get involved in
+Route Filtering unless you have a good supply of aspirin! Once you have
+started down the road of Route Filtering, do not use Isolation either.
+Use one or the other, not both.
+<p>
+You will only require this functionality if you are "well-connected". What
+that means is that you are connected to several different parts of (say)
+the EU cluster and, at the same time, also connected to two or three places
+in the US which, in turn are connected back to the EU. This is called a
+"loop" and if you are seriously looped then you need filtering.
-%nodehops =
+<P>
+I should at this stage give a little bit of background on filters. All
+the filters in Spider work in basically the same way. You can either
+accept or reject various options in order to create the filter rules
+you wish to achieve. Some filters are user settable, others can only
+be altered by the sysop. Route filtering can only be done by the sysop.
- GB7ADX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
+<P>
+Anyway, without further discouragement, let me start the process
+of explanation.
- GB7UDX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
- GB7BAA => {
- 11 => 5,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-};
-</verb></tscreen>
+<sect1>The node_default filter
<P>
-Each set of hops is contained within a pair of curly braces and contains a
-series of PC frame types. PC11 for example is a DX spot. The figures here
-are not exhaustive but should give you a good idea of how the file works.
+All normal systems should have a default routing filter and it should
+usually be set to send only the normal, unlooped, view of your
+"national" network. Here in the UK that means nodes from the UK and
+Eire, in EU it is more complex as the networks there grew up in a more
+intertwined way.
-<P>
-You can alter this file at any time, including whilst the cluster is running.
-If you alter the file during runtime, the command <em>load/hops</em> will
-bring your changes into effect.
+<p>
+The generic commands are:-
-<sect1>Isolating networks
+<tscreen><verb>
+reject/route node_default <filter_option>
-<P>
-It is possible to isolate networks from each other on a "gateway" node using the
- <em>set/isolate <node_call></em> command.
-
-<P>
-The effect of this is to partition an isolated network completely from another
-nodes connected to your node. Your node will appear on and otherwise behave
-normally on every network to which you are connected, but data from an isolated
-network will not cross onto any other network or vice versa. However all the
-spot, announce and WWV traffic and personal messages will still be handled
-locally (because you are a real node on all connected networks), that is locally
-connected users will appear on all networks and will be able to access and
-receive information from all networks transparently. All routed messages will
-be sent as normal, so if a user on one network knows that you are a gateway for
-another network, he can still still send a talk/announce etc message via your
-node and it will be routed across.
+or
-<P>
-The only limitation currently is that non-private messages cannot be passed down
-isolated links regardless of whether they are generated locally. This will change
-when the bulletin routing facility is added.
+accept/route node_default <filter_option>
+</verb></tscreen>
-<P>
-If you use isolate on a node connection you will continue to receive all
-information from the isolated partner, however you will not pass any information
-back to the isolated node. There are times when you would like to forward only
-spots across a link (maybe during a contest for example). To do this, isolate
-the node in the normal way and put in a filter in the /spider/filter/spots
-directory to override the isolate. This filter can be very simple and consists
-of just one line ....
+where filter_option is one of the following ...
<tscreen><verb>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+call <prefixes>
+call_dxcc <numbers>
+call_itu <numbers>
+call_zone <numbers>
+channel <prefixes>
+channel_dxcc <numbers>
+channel_itu <numbers>
+channel_zone <numbers>
</verb></tscreen>
-<P>
-There is a lot more on filtering in the next section.
-
-<sect>Filtering (Old Style upto v1.44)
-
-<P>
-Filters can be set for spots, announcements and WWV. You will find the
-directories for these under /spider/filter. You will find some examples in
-the directories with the suffix <em>.issue</em>. There are two types of
-filter, one for incoming information and one for outgoing information.
-Outgoing filters are in the form <em>CALLSIGN.pl</em> and incoming filters
-are in the form <em>in_CALLSIGN.pl</em>. Filters can be set for both nodes
-and users.
+Please be careful if you alter this setting, it will affect
+<bf><it>ALL</it></bf> your links! Remember, this is a <it>default</it>
+filter for node connections, not a <it>per link</it> default.
-<P>
-All filters work in basically the same way. There are several elements
-delimited by commas. There can be many lines in the filter and they are
-read from the top by the program. When writing a filter you need to think
-carefully about just what you want to achieve. You are either going to write
-a filter to <em>accept</em> or to <em>reject</em>. Think of a filter as
-having 2 main elements. For a reject filter, you would have a line or multiple
-lines rejecting the things you do not wish to receive and then a default line
-accepting everything else that is not included in the filter. Likewise, for an
-accept filter, you would have a line or multiple lines accepting the things you
-wish to receive and a default line rejecting everthing else.
-
-<P>
-In the example below, a user requires a filter that would only return SSB spots
-posted in Europe on the HF bands. This is achieved by first rejecting the CW
-section of each HF band and rejecting all of VHF, UHF etc based on frequency.
-Secondly, a filter rule is set based on CQ zones to only accept spots posted in
-Europe. Lastly, a default filter rule is set to reject anything outside the filter.
+<p>
+For the default routing filter then you have two real choices: either
+a "national" view or the "safe" option of only your own
+callsign. Examples of each (for my node: GB7DJK) are:-
<tscreen><verb>
-$in = [
- [ 0, 0, 'r', # reject all CW spots
- [
- 1800.0, 1850.0,
- 3500.0, 3600.0,
- 7000.0, 7040.0,
- 14000.0, 14100.0,
- 18068.0, 18110.0,
- 21000.0, 21150.0,
- 24890.0, 24930.0,
- 28000.0, 28180.0,
- 30000.0, 49000000000.0,
- ] ,1 ],
- [ 1, 11, 'n', [ 14, 15, 16, 20, 33, ], 15 ], #accept EU
- [ 0, 0, 'd', 0, 1 ], # 1 = want, 'd' = everything else
-];
+acc/route node_default call_dxcc 61,38
+acc/route node_default call gb7djk
</verb></tscreen>
-<P>
-The actual elements of each filter are described more fully in the following
-sections.
+GB7DJK uses the first of these. The DXCC countries can be obtained from the
+<it>show/prefix</it> command.
-<sect1>Spots
+<p>
+The example filters shown control <it>output</it> <bf>TO</bf> all your
+partner nodes unless they have a specific filter applied to them (see
+next section).
-<P>
-The elements of the Spot filter are ....
+<p>
+It is also possible to control the <it>incoming</it> routing
+information that you are prepared to accept <bf>FROM</bf> your partner
+nodes. The reason this is necessary is to make sure that stuff like
+mail, pings and similar commands a) go down the correct links and b)
+don't loop around excessively. Again using GB7DJK as an example a typical
+default input filter would be something like:
<tscreen><verb>
-[action, field_no, sort, possible_values, hops]
+rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38
</verb></tscreen>
-<P>
-There are 3 elements here to look at. Firstly, the action element. This is
-very simple and only 2 possible states exist, accept (1) or drop (0).
+What this does is accept node and user information for our national
+network from nodes that are in our national network, but rejects such
+information from anyone else. Although it doesn't explicitly say so,
+by implication, any other node information (not from the UK and Eire)
+is accepted.
-<P>
-The second element is the field_no. There are 13 possiblities to choose from
-here ....
+<p>
+As I imagine it will take a little while to get one's head around all of
+this you can study the effect of any rules that you try by watching the
+debug output after having done:-
<tscreen><verb>
- 0 = frequency
- 1 = call
- 2 = date in unix format
- 3 = comment
- 4 = spotter
- 5 = spotted dxcc country
- 6 = spotter's dxcc country
- 7 = origin
- 8 = spotted itu
- 9 = spotted cq
- 10 = spotter's itu
- 11 = spotter's cq
- 12 = callsign of the channel on which the spot has appeared
+set/debug filter
</verb></tscreen>
-<P>
-The third element tells us what to expect in the fourth element. There are
-4 possibilities ....
+After you have got tired of that, to put it back the way it was:-
<tscreen><verb>
- n - numeric list of numbers e.g. [ 1,2,3 ]
- r - ranges of pairs of numbers e.g. between 2 and 4 or 10 to 17 - [ 2,4, 10,17 ]
- a - an alphanumeric regex
- d - the default rule
+unset/debug filter
</verb></tscreen>
-<P>
-The fifth element is simply the hops to set in this filter. This would only
-be used if the filter was for a node of course and overrides the hop count in
-hop_table.pl.
-
-<P>
-So, let's look at an example spot filter. It does not matter in the example
-who the filter is to be used for. So, what do we need in the filter? We need
-to filter the spots the user/node requires and also set a default rule for
-anything else outside the filter. Below is a simple filter that stops spots
-arriving from outside Europe.
-
-<tscreen><verb>$in = [
- [ 0, 4, 'a', '^(K|N|A|W|VE|VA|J)'], # 0 = drop, 'a' = alphanumeric
- [ 1, 0, 'd', 0, 1 ], # 1 = want, 'd' = everything else
- ];
-</verb></tscreen>
-
-<P>
-So the filter is wrapped in between a pair of square brackets. This tells
-Spider to look in between these limits. Then each line is contained within
-its own square brackets and ends with a comma. Lets look carefully at the first
-line. The first element is 0 (drop). Therefore anything we put on this line
-will not be accepted. The next element is 4. This means we are filtering by
-the spotter. The third element is the letter "a" which tells the program to
-expect an alphanumeric expression in the fourth element. The fourth element
-is a list of letters separated by the pipe symbol.
+<sect1>General route filtering
<P>
-What this line does is tell the program to drop any spots posted by anyone in
-the USA, Canada or Japan.
+Exactly the same rules apply for general route filtering. You would
+use either an accept filter or a reject filter like this ...
-<P>
-The second line is the default rule for anything else. The "d" tells us this
-and the line simply reads... accept anything else.
+<tscreen><verb>
+reject/route <node_call> <filter_option>
-<P>
-You can add as many lines as you need to complete the filter but if there are
-several lines of the same type it is neater to enclose them all as one line.
-An example of this is where specific bands are set. We could write this like
-this ....
+or
-<tscreen><verb>
-[ 0,0,'r',[1800.0, 2000.0], 1],
-[ 0,0,'r',[10100.0, 10150.0], 1],
-[ 0,0,'r',[14000.0, 14350.0], 1],
-[ 0,0,'r',[18000.0, 18200.0], 1],
+accept/route <node_call> <filter_option>
</verb></tscreen>
<P>
-But the line below achieves the same thing and is more efficient ....
+Here are some examples of route filters ...
<tscreen><verb>
- [ 0, 0, 'r',
- [
- 1800.0, 2000.0, # top band
- 10100.0, 10150.0, # WARC
- 14000.0, 14350.0, # 20m
- 18000.0, 18200.0, # WARC
- [ ,1 ],
+rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes)
+rej/route all (equiv to [very] restricted mode)
+acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
+acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)
</verb></tscreen>
-
-<sect1>Announcements
-
-<P>
+In practice you will either be opening the default filter out for a
+partner by defining a specific filter for that callsign:-
+
<tscreen><verb>
-
-# This is an example announce or filter allowing only West EU announces
-#
-# The element list is:-
-# 0 - callsign of announcer
-# 1 - destination * = all, <callsign> = routed to the node
-# 2 - text
-# 3 - * - sysop, <some text> - special list eg 6MUK, ' ', normal announce
-# 4 - origin
-# 5 - 0 - announce, 1 - wx
-# 6 - channel callsign (the interface from which this spot came)
-
-$in = [
- [ 1, 0, 'a', '^(P[ABCDE]|DK0WCY|G|M|2|EI|F|ON)' ],
- [ 0, 0, 'd', 0 ]
-];
+acc/route gb7baa all
+acc/route gb7baa input all
</verb></tscreen>
-In this example, only the prefixes listed will be allowed. It is possible to
-be quite specific. The Dutch prefix "P" is followed by several secondary
-identifiers which are allowed. So, in the example, "PA" or "PE" would be ok
-but not "PG". It is even possible to allow information from a single callsign.
-In the example this is DK0WCY, to allow the posting of his Aurora Beacon.
-
-<sect1>WWV
+or restricting it quite a lot, in fact making it very nearly like an
+<it>isolated</it> node, like this:-
-<P>
<tscreen><verb>
-
-# This is an example WWV filter
-#
-# The element list is:-
-# 0 - nominal unix date of spot (ie the day + hour:13)
-# 1 - the hour
-# 2 - SFI
-# 3 - K
-# 4 - I
-# 5 - text
-# 6 - spotter
-# 7 - origin
-# 8 - incoming interface callsign
-
-# this one doesn't filter, it just sets the hop count to 6 and is
-# used mainly just to override any isolation from WWV coming from
-# the internet.
-
-$in = [
- [ 1, 0, 'd', 0, 6 ]
-];
-
+acc/route pi4ehv-8 call gb7djk
+rej/route pi4ehv-8 input call_dxcc 61,38
</verb></tscreen>
-<P>
-It should be noted that the filter will start to be used only once a user/node
-has logged out and back in again.
-<P>
-I am not going to spend any more time on these filters now as they will become
-more "comprehensive" in the near future.
+This last example takes everything except UK and Eire from PI4EHV-8
+but only sends him my local configuration (just a PC19 for GB7DJK and
+PC16s for my local users).
+
+<p>
+It is possible to write <bf>much</bf> more complex rules, there are up
+to 10 accept/reject pairs per callsign per filter. For more information
+see the next section.
-<sect>Filtering (New Style v1.45 and later)
<sect1>General filter rules
DXSpider system. They all use the same general mechanism.
<P>
-In general terms you can create a 'reject' or an 'accept' filter which can have
+In general terms you can create a "reject" or an "accept" filter which can have
up to 10 lines in it. You do this using, for example ...
<tscreen><verb>
an 'accept' slot. The reject slot is executed BEFORE the accept slot.
<P>
-It was mentioned earlier that after a reject test that doesn't match, the default
-for following tests is 'accept', the reverse is true for 'accept'. In the example
-what happens is that the reject is executed first, any non hf/cw spot is passed
-to the accept line, which lets through everything else on HF. The next filter line
-lets through just VHF/UHF spots from EU.
+It was mentioned earlier that after a reject test that doesn't match, the default
+for following tests is 'accept', the reverse is true for 'accept'. In the example
+what happens is that the reject is executed first, any non hf/cw spot is passed
+to the accept line, which lets through everything else on HF. The next filter line
+lets through just VHF/UHF spots from EU.
+
+<sect1>Basic hop control
+
+<P>
+In /spider/data you will find a file called hop_table.pl. This is the file
+that controls your hop count settings. It has a set of default hops on the
+various PC frames and also a set for each node you want to alter the hops for.
+You may be happy with the default settings of course, but this powerful tool
+can help to protect and improve the network. The file will look something
+like this ...
+
+<tscreen><verb>
+#
+# hop table construction
+#
+
+package DXProt;
+
+# default hopcount to use
+$def_hopcount = 5;
+
+# some variable hop counts based on message type
+%hopcount =
+(
+ 11 => 10,
+ 16 => 10,
+ 17 => 10,
+ 19 => 10,
+ 21 => 10,
+);
+
+
+# the per node hop control thingy
+
+
+%nodehops =
+
+ GB7ADX => { 11 => 8,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+
+ GB7UDX => { 11 => 8,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+ GB7BAA => {
+ 11 => 5,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+};
+</verb></tscreen>
+
+<P>
+Each set of hops is contained within a pair of curly braces and contains a
+series of PC frame types. PC11 for example is a DX spot. The figures here
+are not exhaustive but should give you a good idea of how the file works.
+
+<P>
+SHould any of the nodecalls include an ssid, it is important to wrap the
+whole call in single quotes, like this ...
+
+<tscreen><verb>
+ 'DB0FHF-15' => {
+ 11 => 5,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+</verb></tscreen>
+
+If you do not do this, you will get errors and the file will not work as
+expected.
+
+<P>
+You can alter this file at any time, including whilst the cluster is running.
+If you alter the file during runtime, the command <em>load/hops</em> will
+bring your changes into effect.
+
+<sect1>Hop Control on Specific Nodes
+
+<p>You can set a callsign specific hop count for any of the standard filter
+options so:-
+
+<tscreen><verb>
+set/hops gb7djk spot 4
+set/hops node_default route 10
+set/hops gb7baa wcy 5
+</verb></tscreen>
+
+all work on their specific area of the protocol.
+
+<p>
+The <em>set/hops</em> command overrides any hops that you have set otherwise.
+
+<p>
+You can set what hops have been set using the <em>show/hops</em> command.
+
+<sect1>Isolating networks
+
+<P>
+It is possible to isolate networks from each other on a "gateway" node using the
+ <em>set/isolate <node_call></em> command.
+
+<P>
+The effect of this is to partition an isolated network completely from another
+node connected to your node. Your node will appear on and otherwise behave
+normally on every network to which you are connected, but data from an isolated
+network will not cross onto any other network or vice versa. However all the
+spot, announce and WWV traffic and personal messages will still be handled
+locally (because you are a real node on all connected networks), that is locally
+connected users will appear on all networks and will be able to access and
+receive information from all networks transparently. All routed messages will
+be sent as normal, so if a user on one network knows that you are a gateway for
+another network, he can still still send a talk/announce etc message via your
+node and it will be routed across.
+<P>
+If you use isolate on a node connection you will continue to receive
+all information from the isolated partner, however you will not pass
+any information back to the isolated node. There are times when you
+would like to forward only spots across a link (maybe during a contest
+for example). To do this, isolate the node in the normal way and use
+an <em>acc/spot >call< all</em> filter to override the isolate.
<sect>Other filters
the other cluster nodes that we are linked to. This is usually because of
rules and regulations pertaining to items for sale etc in a particular country.
-<sect1>Filtering DX callouts (Depricated)
-<P>
-<bf><it>From version 1.47, this method is replaced by the command set/baddx</it></bf>
+<sect1>Filtering words from text fields in Announce, Talk and DX spots
-<P>
-In the same way as mail, there are some types of spot we do not wish to pass on
-to users or linked cluster nodes. In the /spider/data directory you will find
-a file called baddx.pl.issue. Rename this to baddx.pl and edit the file. The
-original looks like this ....
+<p>
+From version 1.48 onwards the interface to this has changed. You can now
+use the commands <em>set/badword</em> to add words that you are not prepared
+to see on the cluster, <em>unset/badword</em> to allow that word again and
+<em>show/badword</em> to list the words that you have set.
-<tscreen><verb>
+<p>
+If you have a previous <em>/spider/data/badwords</em>, the first time you start
+the node, it will read and convert this file to the new commands. The old style
+file will then be removed.
-# the list of dx spot addresses that we don't store and don't pass on
+<sect1>Stopping (possibly bad) DX Spots from Nodes or Spotters
+<p>
+There are a number of commands that control whether a spot progresses
+any further by regarding it as "bad" in some way.
-package DXProt;
+<p>
+A DX Spot has a number of fields which can be checked to see whether they
+contain "bad" values, they are: the DX callsign itself, the Spotter and
+the Originating Node.
-@baddx = qw
-
- FROG
- SALE
- FORSALE
- WANTED
- P1RATE
- PIRATE
- TEST
- DXTEST
- NIL
- NOCALL
-);
-</verb></tscreen>
+<p>
+There are a set of commands which allow the sysop to control whether a
+spot continues:-
-<P>
-Again, this is simply a list of names we do not want to see in the spotted
-field of a DX callout.
+<tscreen><verb>
+set/baddx
+set/badspotter
+set/badnode
+</verb></tscreen>
+These work in the same as the <em>set/badword</em> command, you can add
+any words or callsigns or whatever to the appropriate database. For
+example, to stop a spot from a particular node you do:
-<sect1>Filtering words from text fields in Announce, Talk and DX spots
+<tscreen><verb>
+set/badnode gb7djk gb7dxc
+</verb></tscreen>
-<P>
-Create a file in /spider/data called <em>badwords</em>. The format is quite
-simple. Lines beginning with # are ignored so comments can be added. An
-example file is below ...
+a bad spotter:
<tscreen><verb>
-# Below is a list of words we do not wish to see on the cluster
-grunge grunged grunging
-splodge splodger splodging
-grince
-fluffle
+set/badspotter b0mb p1rat nocall
</verb></tscreen>
-Multiple words can be used on the same line as shown. Obviously these
-are just examples :-)
+and some bad dx:
-<P>
-You can reload the file from the cluster prompt as sysop with load/badwords.
+<tscreen><verb>
+set/baddx video wsjt
+</verb></tscreen>
+
+You can remove a word using the appropriate unset command
+(<em>unset/baddx, unset/badspotter, unset/badnode</em>) or list them
+using one of <em>show/baddx, show/badspotter</em> and
+<em>show/badnode</em>.
<sect>Mail
Make sure you only send mail to the clusters that want it by using the
Forward.pl file very carefully.
+<sect>Scripts
+
+<p>
+From 1.48 onwards it will become increasingly possible to control DXSpider's
+operation with scripts of various kinds.
+
+<P>
+The directory /spider/scripts is where it all happens and is used for several
+things. Firstly it contains a file called startup that can be used to call
+in any changes to the cluster from the default settings on startup. This
+script is executed immediately after all initialisation of the node is done
+but before any connections are possible. Examples of this include how many
+spots it is possible to get with the sh/dx command, whether you want
+registration/passwords to be permanently on etc. An example file is shown
+below and is included in the distribution as startup.issue.
+
+<tscreen><verb>
+#
+# startup script example
+#
+# set maximum no of spots allowed to 100
+# set/var $Spot::maxspots = 1
+#
+# Set registration on
+# set/var $main::reqreg = 1
+#
+# Set passwords on
+# set/var $main::passwdreq = 1
+#
+</verb></tscreen>
+
+<P>
+As usual, any text behind a # is treated as a comment and not read. To use
+this file, simply rename it from startup.issue to startup. In our example
+above there are three options. The first option is the amount of spots that
+a user can request with the <em>sh/dx</em> command. Normally the default is
+to give 10 spots unless the user specifies more. Without this line enabled,
+the maximum a user can request is 100 spots. Depending on your link quality
+you may wish to enable more or less by specifying the number. If you simply
+uncomment the line, the maximum would be 1 spot!
+
+<P>
+The other 2 options are dealt with more fully in the security section.
+
+<P>
+Secondly, it is used to store the login scripts for users and nodes. Currently
+this can only be done by the sysop but it is envisaged that eventually users will
+be able to set their own. An example is included in the distibution but here is
+a further example.
+
+<tscreen><verb>
+#
+# G0FYD
+#
+blank +
+sh/wwv 3
+blank +
+sh/dx
+blank +
+t g0jhc You abt?
+blank +
+</verb></tscreen>
+
+The lines in between commands can simply insert a blank line or a character
+such as a + sign to make the output easier to read. Simply create this script
+with your favourite editor and save it with the callsign of the user as the
+filename. Filenames should always be in lower case.
+
+<P>
+Commands can be inserted in the same way for nodes. A node may wish a series
+of commands to be issued on login, such as a merge command for example.
+
+<P>
+Thirdly, there are 2 default scripts for users and nodes who do not have a
+specifically defined script. These are <em>user_default</em> and
+<em>node_default</em>
+
<sect>Databases
<P>
and edit it to say whatever you want. It is purely a text file and will be
sent automatically to anyone logging in to the cluster.
+<sect1>MOTD_NOR
+
+<P>
+This message of the day file lives in the same directory as the standard
+motd file but is only sent to non-registered users. Once registered they
+will receive the same message as any other user.
+
<sect1>Downtime message
<P>
<sect1>The Aliases file
<P>
-You will find a file in /spider/cmd/ called Aliases. First, copy this file to
-/spider/local_cmd/Aliases and edit this file. You will see something like this ...
+You will find a file in /spider/cmd/ called Aliases. This is the file that
+controls what a user gets when issuing a command. It is also possible to
+create your own aliases for databases and files you create locally.
-<tscreen><verb>
-
-#!/usr/bin/perl
-
-# provide some standard aliases for commands for terminally
-# helpless ak1a user (helpless in the sense that they never
-# read nor understand help files)
-
-# This file is automagically reloaded if its modification time is
-# later than the one stored in CmdAlias.pm
-
-# PLEASE make this file consistant with reality! (the patterns MUST
-# match the filenames!)
-
-# Don't alter this file, copy it into the local_cmd tree and modify it.
-# This file will be replaced everytime I issue a new release.
+<P>
+You should not alter the original file in /spider/cmd/ but create a new file
+with the same name in /spider/local_cmd. This means that any new Aliases files
+that is downloaded will not overwrite your self created Aliases and also that
+you do not override any new Aliases with your copy in /spider/local_cmd/. You
+must remember that any files you store in /spider/local/ or /spider/local_cmd
+override the originals if the same lines are used in both files.
-# You only need to put aliases in here for commands that don't work as
-# you desire naturally, e.g sh/dx on its own just works as you expect
-# so you need not add it as an alias.
+<P>
+The best way of dealing with all this then is to only put your own locally
+created Aliases in the copy in /spider/local_cmd. The example below is
+currently in use at GB7MBC.
+<tscreen><verb>
+#
+# Local Aliases File
+#
package CmdAlias;
%alias = (
- '?' => [
- '^\?', 'apropos', 'apropos',
- ],
- 'a' => [
- '^ann.*/full', 'announce full', 'announce',
- '^ann.*/sysop', 'announce sysop', 'announce',
- '^ann.*/(.*)$', 'announce $1', 'announce',
- ],
- 'b' => [
- ],
- 'c' => [
- ],
- 'd' => [
- '^del', 'kill', 'kill',
- '^del\w*/fu', 'kill full', 'kill',
- '^di\w*/a\w*', 'directory all', 'directory',
- '^di\w*/b\w*', 'directory bulletins', 'directory',
- '^di\w*/n\w*', 'directory new', 'directory',
- '^di\w*/o\w*', 'directory own', 'directory',
- '^di\w*/s\w*', 'directory subject', 'directory',
- '^di\w*/t\w*', 'directory to', 'directory',
- '^di\w*/f\w*', 'directory from', 'directory',
- '^di\w*/(\d+)', 'directory $1', 'directory',
- ],
- 'e' => [
- ],
- 'f' => [
- ],
- 'g' => [
- ],
- 'h' => [
- ],
- 'i' => [
- ],
- 'j' => [
- ],
- 'k' => [
- ],
- 'l' => [
- '^l$', 'directory', 'directory',
- '^ll$', 'directory', 'directory',
- '^ll/(\d+)', 'directory $1', 'directory',
- ],
- 'm' => [
- ],
- 'n' => [
- '^news', 'type news', 'type',
- ],
- 'o' => [
- ],
- 'p' => [
- ],
- 'q' => [
- '^q', 'bye', 'bye',
- ],
- 'r' => [
- '^r$', 'read', 'read',
- '^rcmd/(\S+)', 'rcmd $1', 'rcmd',
- ],
- 's' => [
- '^s/p$', 'send', 'send',
- '^sb$', 'send noprivate', 'send',
- '^set/home$', 'set/homenode', 'set/homenode',
- '^set/nobe', 'unset/beep', 'unset/beep',
- '^set/nohe', 'unset/here', 'unset/here',
- '^set/noan', 'unset/announce', 'unset/announce',
- '^set/nodx', 'unset/dx', 'unset/dx',
- '^set/nota', 'unset/talk', 'unset/talk',
- '^set/noww', 'unset/wwv', 'unset/wwv',
- '^set/nowx', 'unset/wx', 'unset/wx',
- '^sh$', 'show', 'show',
- '^sh\w*/buck', 'dbshow buck', 'dbshow',
- '^sh\w*/bu', 'show/files bulletins', 'show/files',
- '^sh\w*/c/n', 'show/configuration nodes', 'show/configuration',
- '^sh\w*/c$', 'show/configuration', 'show/configuration',
- '^sh\w*/com', 'dbavail', 'dbavail',
- '^sh\w*/dx/(\d+)-(\d+)', 'show/dx $1-$2', 'show/dx',
- '^sh\w*/dx/(\d+)', 'show/dx $1', 'show/dx',
- '^sh\w*/dx/d(\d+)', 'show/dx from $1', 'show/dx',
- '^sh\w*/email', 'dbshow email', 'dbshow',
- '^sh\w*/hftest', 'dbshow hftest', 'dbshow',
- '^sh\w*/vhftest', 'dbshow vhftest', 'dbshow',
- '^sh\w*/qsl', 'dbshow qsl', 'dbshow',
- '^sh\w*/tnc', 'who', 'who',
- '^sh\w*/up', 'show/cluster', 'show/cluster',
- '^sh\w*/w\w*/(\d+)-(\d+)', 'show/wwv $1-$2', 'show/wwv',
- '^sh\w*/w\w*/(\d+)', 'show/wwv $1', 'show/wwv',
- '^sp$', 'send', 'send',
-
+ 'n' => [
+ '^news$', 'type news', 'type',
],
- 't' => [
- '^ta$', 'talk', 'talk',
- '^t$', 'talk', 'talk',
- ],
- 'u' => [
- ],
- 'v' => [
- ],
- 'w' => [
- '^wx/full', 'wx full', 'wx',
- '^wx/sysop', 'wx sysop', 'wx',
- ],
- 'x' => [
- ],
- 'y' => [
- ],
- 'z' => [
+ 's' => [
+ '^sh\w*/buck$', 'show/qrz', 'show',
+ '^sh\w*/hftest$', 'dbshow hftest', 'dbshow',
+ '^sh\w*/qsl$', 'dbshow qsl', 'dbshow',
+ '^sh\w*/vhf$', 'dbshow vhf', 'dbshow',
+ '^sh\w*/vhftest$', 'dbshow vhftest', 'dbshow',
],
)
+
</verb></tscreen>
-You can create aliases for commands at will. Beware though, these may not
-always turn out as you think. Care is needed and you need to test the
-results once you have set an alias.
+<P>
+Each alphabetical section should be preceded by the initial letter and the section
+should be wrapped in square brackets as you can see. The syntax is straightforward.
+The first section on each line is the new command that will be allowed once the
+alias is included. The second section is the command it is replacing and the last
+section is the actual command that is being used.
+
+<P>
+The eagle-eyed amongst you will have noticed that in the first section, the new
+alias command has a '^' at the start and a '$' at the end. Basically these force
+a perfect match on the alias. The '^' says match the beginning exactly and the
+'$' says match the end exactly. This prevents unwanted and unintentional matches
+with similar commands.
+
+<P>
+I have 3 different types of alias in this file. At the top is an alias for 'news'.
+This is a file I have created in the /spider/packclus/ directory where I can inform
+users of new developments or points of interest. In it's initial form a user would
+have to use the command <em>type news</em>. The alias allows them to simply type
+<em>news</em> to get the info. Second is an alias for the <em>show/qrz</em>
+command so that those users used to the original <em>show/buck</em> command in
+AK1A will not get an error, and the rest of the lines are for locally created
+databases so that a user can type <em>show/hftest</em> instead of having to use
+the command <em>dbshow hftest</em> which is not as intuitive.
+
+<P>
+This file is just an example and you should edit it to your own requirements.
+Once created, simply issue the command <em>load/alias</em> at the cluster
+prompt as the sysop user and the aliases should be available.
+
<sect1>Console.pl
export 5467 /spider/perl/keps.in
</verb></tscreen>
+<P>
would export message number 5467 as a file called keps.in in the
/spider/perl directory.
+<P>
Now login to a VT as sysop and cd /spider/perl. There is a command in
the perl directory called <em>convkeps.pl</em>. All we need to do now is
convert the file like so ...
./convkeps.pl keps.in
</verb></tscreen>
+<P>
Now go back to the cluster and issue the command ...
<tscreen><verb>
load/keps
</verb></tscreen>
+<P>
That is it! the kepler data has been updated.
<sect1>The QRZ callbook
the setup. Many thanks to Fred Lloyd, the proprieter of
<htmlurl url="http://www.qrz.com" name="qrz.com"> for allowing this access.
+<sect>Security
+
+<P>
+From version 1.49 DXSpider has some additional security features. These
+are not by any means meant to be exhaustive, however they do afford some
+security against piracy. These two new features can be used independently
+of each other or in concert to tighten the security.
+
+<sect1>Registration
+
+<P>
+The basic principle of registration is simple. If a user is not registered
+by the sysop, then they have read-only access to the cluster. The only
+thing they can actually send is a talk or a message to the sysop. In
+order for them to be able to spot, send announces or talks etc the sysop
+must register them with the <em>set/register</em> command, like this ...
+
+<tscreen><verb>
+set/register g0vgs
+</verb></tscreen>
+
+The user g0vgs can now fully use the cluster. In order to enable
+registration, you can issue the command ...
+
+<tscreen><verb>
+set/var $main::reqreg = 1
+</verb></tscreen>
+
+Any users that are not registered will now see the motd_nor file rather
+than the motd file as discussed in the Information, files and useful
+programs section.
+
+<P>
+Entering this line at the prompt will only last for the time the cluster
+is running of course and would not be present on a restart. To make the
+change permanent, add the above line to /spider/scripts/startup. To
+read more on the startup file, see the section on Information, files
+and useful programs.
+
+<P>
+To unregister a user use <em>unset/register</em> and to show the list
+of registered users, use the command <em>show/register</em>.
+
+<sect1>Passwords
+
+<P>
+At the moment, passwords only affect users who login to a DXSpider
+cluster node via telnet. If a user requires a password, they can
+either set it themselves or have the sysop enter it for them by using
+the <em>set/password</em> command. Any users who already have passwords,
+such as remote sysops, will be asked for their passwords automatically
+by the cluster. Using passwords in this way means that the user has a
+choice on whether to have a password or not. To force the use of
+passwords at login, issue the command ...
+
+<tscreen><verb>
+set/var $main::passwdreq = 1
+</verb></tscreen>
+
+at the cluster prompt. This can also be added to the /spider/scripts/startup
+file as above to make the change permanent.
+
+<P>
+Of course, if you do this you will have to assign a password for each of
+your users. If you were asking them to register, it is anticipated that
+you would ask them to send you a message both to ask to be registered and
+to give you the password they wish to use.
+
+<P>
+Should a user forget their password, it can be reset by the sysop by
+first removing the existing password and then setting a new one like so ...
+
+<tscreen><verb>
+unset/password g0vgs
+set/password g0vgs new_password
+</verb></tscreen>
+
<sect>CVS
<P>
sources by using a few simple commands.
<P>
-THIS IS NOT FOR THE FAINT HEARTED!!! ONLY DO THIS IF YOU HAVE A TEST
-INSTALLATION OR ARE WILLING TO HAVE YOUR CLUSTER CRASH ON YOU!!!
-THIS MUST BE CONSIDERED AT LEAST BETA TESTING AND MAYBE EVEN ALPHA!!
-YOU HAVE BEEN WARNED!!!
-
-<P>
-DID I MENTION..... ONLY DO THIS IF YOU ARE WILLING TO ACCEPT THE
-CONSEQUENCES!!!
+Please be aware that if you update your system using CVS, it is possible that
+you could be running code that is very beta and not fully tested. There is
+a possibility that it could be unstable.
<P>
I am of course assuming that you have a machine with both DXSpider and
accept/ann user_default by G,M,2
</verb></tscreen>
+<sect1>accept/route (8)
+
+<P>
+<tt>
+<bf>accept/route <call> [0-9] <pattern></bf> Set an 'accept' filter line for routing
+</tt>
+
+<P>
+Create an 'accept this routing PC Protocol' line for a filter.
+
+<P>
+An accept filter line means that if a PC16/17/19/21/24/41/50 matches this filter
+it is passed thru that interface. See HELP FILTERING for more info. Please read this
+to understand how filters work - it will save a lot of grief later on.
+
+<P>
+You can use any of the following things in this line:-
+
+<tscreen><verb>
+ call <prefixes> the callsign of the thingy
+ call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
+ call_itu <numbers>
+ call_zone <numbers>
+ origin <prefixes> really the interface it came in on
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
+ origin_itu <numbers>
+ origin_zone <numbers>
+</verb></tscreen>
+
+<P>
+some examples:-
+
+<tscreen><verb>
+ acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
+ acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)
+</verb></tscreen>
+
+<P>
+You can use the tag 'all' to accept everything eg:
+
+<tscreen><verb>
+ acc/route all
+</verb></tscreen>
+
<sect1>accept/spots (0)
<P>
<tt>
-<bf>accept/announce [0-9] <pattern></bf> Set an accept filter
+<bf>accept/spots [0-9] <pattern></bf> Set an accept filter
line for spots
</tt>
<P>
Send an announcement to LOCAL users only, where <text> is the text
-of the announcement you wish to broadcast
+of the announcement you wish to broadcast. If you do not wish to receive
+announces, use the <em>set/noannounce</em> command. Any announces made by
+a sysop will override set/noannounce.
<sect1>announce full (0)
Order is not important.
+<sect1>clear/announce (8)
+
+<P>
+<tt>
+<bf>clear/announce [input] <callsign> [0-9|all]</bf> Clear an announce filter line
+</tt>
+
+<P>
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
+
+<sect1>clear/route (8)
+
+<P>
+<tt>
+<bf>clear/route [input] ^lt;callsign> [0-9|all]</bf> Clear a route filter line
+</tt>
+
+<P>
+This command allows you to clear (remove) a line in a route filter or to
+remove the whole filter.
+
+see CLEAR/SPOTS for a more detailed explanation.
+
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
+
<sect1>clear/spots (0)
<P>
the filter will be completely removed.
+<sect1>clear/spots (extended for sysops) (8)
+
+<P>
+<tt>
+<bf>clear/spots [input] <callsign> [0-9|all]</bf> Clear a spot filter line
+</tt>
+
+<P>
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
+
+<sect1>clear/wcy (0)
+
+<P>
+<tt>
+<bf>clear/wcy [1|all]</bf> Clear a WCY filter line
+</tt>
+
+<P>
+This command allows you to clear (remove) a line in a WCY filter or to
+remove the whole filter.
+
+see CLEAR/SPOTS for a more detailed explanation.
+
+<sect1>clear/wcy (extended for sysops) (8)
+
+<P>
+<tt>
+<bf>clear/wcy [input] <callsign> [0-9|all]</bf> Clear a WCY filter line
+</tt>
+
+<P>
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
+
+<sect1>clear/wwv (0)
+
+<P>
+<tt>
+<bf>clear/wwv [1|all]</bf> Clear a WWV filter line
+</tt>
+
+<P>
+This command allows you to clear (remove) a line in a WWV filter or to
+remove the whole filter.
+
+see CLEAR/SPOTS for a more detailed explanation.
+
+<sect1>clear/wwv (extended for sysops) (8)
+
+<P>
+<tt>
+<bf>clear/wwv [input] <callsign> [0-9|all]</bf> Clear a WWV filter line
+</tt>
+
+<P>
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
<sect1>connect (5)
perl -d cluster.pl
</verb></tscreen>
-It will interrupt the cluster just after the debug command has finished.
+It will interrupt the cluster just after the debug command has finished.
+
+<sect1>delete/user (9)
+
+<P>
+<tt>
+<bf>delete/user <callsign></bf> Delete a user from the User Database
+</tt>
+
+<P>
+This command will completely remove a one or more users from the database.
+
+There is NO SECOND CHANCE.
+
+It goes without saying that you should use this command CAREFULLY!
+
<sect1>directory (0)
BE WARNED: this will write to any file you have write access to. No check is
made on the filename (if any) that you specify.
+<sect1>filtering (0)
+
+<P>
+<tt>
+<bf>filtering</bf> Filtering things in DXSpider
+</tt>
+
+<P>
+There are a number of things you can filter in the DXSpider system. They
+all use the same general mechanism.
+
+In general terms you can create a 'reject' or an 'accept' filter which
+can have up to 10 lines in it. You do this using, for example:-
+
+ accept/spots .....
+ reject/spots .....
+
+where ..... are the specific commands for that type of filter. There
+are filters for spots, wwv, announce, wcy and (for sysops)
+connects. See each different accept or reject command reference for
+more details.
+
+There is also a command to clear out one or more lines in a filter and
+one to show you what you have set. They are:-
+
+ clear/spots 1
+ clear/spots all
+
+and
+
+ show/filter
+
+There is clear/xxxx command for each type of filter.
+
+For now we are going to use spots for the examples, but you can apply
+the principles to all types of filter.
+
+There are two main types of filter 'accept' or 'reject'; which you use
+depends entirely on how you look at the world and what is least
+writing to achieve what you want. Each filter has 10 lines (of any
+length) which are tried in order. If a line matches then the action
+you have specified is taken (ie reject means ignore it and accept
+means gimme it).
+
+The important thing to remember is that if you specify a 'reject'
+filter (all the lines in it say 'reject/spots' (for instance) then if
+a spot comes in that doesn't match any of the lines then you will get
+it BUT if you specify an 'accept' filter then any spots that don't
+match are dumped. For example if I have a one line accept filter:-
+
+ accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
+
+then automatically you will ONLY get VHF spots from or to CQ zones 14
+15 and 16. If you set a reject filter like:
+
+ reject/spots on hf/cw
+
+Then you will get everything EXCEPT HF CW spots, If you am interested in IOTA
+and will work it even on CW then you could say:-
+
+ reject/spots on hf/cw and not info iota
+
+But in that case you might only be interested in iota and say:-
+
+ accept/spots not on hf/cw or info iota
+
+which is exactly the same. You should choose one or the other until
+you are confortable with the way it works. Yes, you can mix them
+(actually you can have an accept AND a reject on the same line) but
+don't try this at home until you can analyse the results that you get
+without ringing up the sysop for help.
+
+You can arrange your filter lines into logical units, either for your
+own understanding or simply convenience. I have one set frequently:-
+
+ reject/spots 1 on hf/cw
+ reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)
+
+What this does is to ignore all HF CW spots (being a class B I can't
+read any CW and couldn't possibly be interested in HF :-) and also
+rejects any spots on VHF which don't either originate or spot someone
+in Europe.
+
+This is an exmaple where you would use the line number (1 and 2 in
+this case), if you leave the digit out, the system assumes '1'. Digits
+'0'-'9' are available.
+
+You can leave the word 'and' out if you want, it is implied. You can
+use any number of brackets to make the 'expression' as you want
+it. There are things called precedence rules working here which mean
+that you will NEED brackets in a situation like line 2 because,
+without it, will assume:-
+
+ (on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16
+
+annoying, but that is the way it is. If you use OR - use
+brackets. Whilst we are here CASE is not important. 'And BY_Zone' is
+just 'and by_zone'.
+
+If you want to alter your filter you can just redefine one or more
+lines of it or clear out one line. For example:-
+
+ reject/spots 1 on hf/ssb
+
+or
+
+ clear/spots 1
+
+To remove the filter in its entirty:-
+
+ clear/spots all
+
+There are similar CLEAR commands for the other filters:-
+
+ clear/announce
+ clear/wcy
+ clear/wwv
+
+ADVANCED USERS:-
+
+Once you are happy with the results you get, you may like to experiment.
+
+my example that filters hf/cw spots and accepts vhf/uhf spots from EU
+can be written with a mixed filter, eg:
+
+ rej/spot on hf/cw
+ acc/spot on 0/30000
+ acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)
+
+each filter slot actually has a 'reject' slot and an 'accept'
+slot. The reject slot is executed BEFORE the accept slot.
+
+It was mentioned earlier that after a reject test that doesn't match,
+the default for following tests is 'accept', the reverse is true for
+'accept'. In the example what happens is that the reject is executed
+first, any non hf/cw spot is passed to the accept line, which lets
+thru everything else on HF.
+
+The next filter line lets through just VHF/UHF spots from EU.
+
<sect1>forward/latlong (8)
<P>
This uses the subject field, so any messages that have exactly the same subject
will be deleted. Beware!
+<sect1>kill/expunge (6)
+
+<P>
+<tt>
+<bf>kill/expunge <msgno> [<msgno>..]</bf>Expunge a message
+</tt>
+
+<P>
+Deleting a message using the normal KILL commands only marks that message
+for deletion. The actual deletion only happens later (usually two days later).
+
+The KILL EXPUNGE command causes the message to be truly deleted more or less
+immediately.
+
+It otherwise is used in the same way as the KILL command.
+
+
<sect1>links (0)
<P>
do this if you change this file whilst the cluster is running in order for the
changes to take effect.
-
-<sect1>load/baddx (9)
-
-<P>
-<tt>
-<bf>load/baddx</bf> Reload the bad DX table
-</tt>
-
-<P>
-Reload the /spider/data/baddx.pl file if you have changed it manually whilst
-the cluster is running. This table contains the DX Calls that, if spotted,
-will not be passed on. FR0G and TEST are classic examples.
-
<sect1>load/badmsg (9)
<P>
<P>
<tt>
-<bf>load/badwords</bf> Reload the badwords file
+<bf>load/badwords</bf> Reload the bad words table
</tt>
<P>
reject/ann user_default by G,M,2
</verb></tscreen>
+<sect1>reject/route (8)
+
+<P>
+<tt>
+<bf>reject/route <call> [0-9] <pattern></bf> Set an 'reject' filter line for routing
+</tt>
+
+<P>
+Create an 'reject this routing PC Protocol' line for a filter.
+
+<P>
+An reject filter line means that if a PC16/17/19/21/24/41/50 matches this filter
+it is NOT passed thru that interface. See HELP FILTERING for more info. Please
+read this to understand how filters work - it will save a lot of grief later on.
+You can use any of the following things in this line:-
+
+<tscreen><verb>
+ call <prefixes> the callsign of the thingy
+ call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
+ call_itu <numbers>
+ call_zone <numbers>
+ origin <prefixes> really the interface it came in on
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
+ origin_itu <numbers>
+ origin_zone <numbers>
+</verb></tscreen>
+
+<P>
+some examples:-
+
+<tscreen><verb>
+ rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes)
+</verb></tscreen>
+
+<P>
+You can use the tag 'all' to reject everything eg:
+
+<tscreen><verb>
+ rej/route all (equiv to [very] restricted mode)
+</verb></tscreen>
+
<sect1>reject/spots (0)
<P>
Use with extreme care. This command may well be superceded by FILTERing.
+<sect1>set/badword (8)
+
+<P>
+<tt>
+<bf>set/badword <word></bf> Stop things with this word being propogated
+</tt>
+
+<P>
+Setting a word as a 'badword' will prevent things like spots,
+announces or talks with this word in the the text part from going any
+further. They will not be displayed and they will not be sent onto
+other nodes.
+
+The word must be written in full, no wild cards are allowed eg:-
+
+ set/badword annihilate annihilated annihilation
+
+will stop anything with these words in the text.
+
+ unset/badword annihilated
+
+will allow text with this word again.
+
+
<sect1>set/beep (0)
<P>
<P>
Add a beep to DX and other terminal messages.
+<sect1>set/bbs (5)
+
+<P>
+<tt>
+<bf>set/bbs <call> [<call>..]</bf>Make <call> a BBS
+</tt>
+
<sect1>set/clx (5)
<P>
YOU DO NOT NEED TO USE THIS COMMAND IF YOU ARE CONNECTED VIA AX25.
+<sect1>set/email (0)
+
+<P>
+<tt>
+<bf>set/email <email_address></bf> Set email address(es) and forward your personals
+</tt>
+
+<P>
+If any personal messages come in for your callsign then you can use
+these commands to control whether they are forwarded onto your email
+address. To enable the forwarding do something like:-
+
+ SET/EMAIL mike.tubby@somewhere.com
+
+You can have more than one email address (each one separated by a space).
+Emails are forwarded to all the email addresses you specify.
+
+You can disable forwarding by:-
+
+ UNSET/EMAIL
+
<sect1>set/here (0)
<P>
The setting is stored in your user profile.
+<sect1>set/password (0)
+
+<P>
+<tt>
+<bf>set/password</bf> Set your own password
+</tt>
+
+<P>
+This command only works for a 'telnet' user (currently). It will
+only work if you have a password already set. This initial password
+can only be set by the sysop.
+
+When you execute this command it will ask you for your old password,
+then ask you to type in your new password twice (to make sure you
+get it right). You may or may not see the data echoed on the screen
+as you type, depending on the type of telnet client you have.
<sect1>set/password (9)
<P>
The password for a user can only be set by a full sysop. The string
-can contain any characters but any spaces are removed (you can type in
-spaces - but they won't appear in the password). You can see the
-result with STAT/USER. The password is the usual 30 character baycom
-type password.
+can contain any characters.
+
+The way this field is used depends on context. If it is being used in
+the SYSOP command context then you are offered 5 random numbers and you
+have to supply the corresponding letters. This is now mainly for ax25
+connections.
+
+If it is being used on incoming telnet connections then, if a password
+is set or the:
+
+ set/var $main::passwdreq = 1
+
+command is executed in the startup script, then a password prompt is
+given after the normal 'login: ' prompt.
+
+The command "unset/password" is provided to allow a sysop to remove a
+users password completely in case a user forgets or loses their password.
<sect1>set/pinginterval (9)
<P>
-<tt>
-<bf>set/pinginterval <time> <node call></bf> Set the ping time
+<tt><bf>set/pinginterval <time> <node call></bf> Set the ping time
to neighbouring nodes
</tt>
set/qth East Dereham, Norfolk
</verb></tscreen>
+<sect1>set/register (9)
+
+<P>
+<tt>
+<bf>set/register <call></bf> Mark a user as registered
+</tt>
+
+<P>
+Registration is a concept that you can switch on by executing the
+
+ set/var $main::regreq = 1
+
+command (usually in your startup file)
+
+If a user is NOT registered then, firstly, instead of the normal
+motd file (/spider/data/motd) being sent to the user at startup, the
+user is sent the motd_nor file instead. Secondly, the non registered
+user only has READ-ONLY access to the node. The non-registered user
+cannot use DX, ANN etc.
+
+The only exception to this is that a non-registered user can TALK or
+SEND messages to the sysop.
+
+To unset a user use the 'unset/register' command
+
<sect1>set/talk (0)
<P>
Display all the bad spotter's callsigns in the system, see SET/BADSPOTTER
for more information.
+<sect1>show/badword (1)
+
+<P>
+<tt>
+<bf>show/badword</bf> Show all the bad words in the system
+</tt>
+
+<P>
+Display all the bad words in the system, see SET/BADWORD
+for more information.
+
+<sect1>show/configuration (0)
+
+<P>
+<tt>
+<bf>show/configuration [<node>]</bf> Show all visible nodes and their users
+</tt>
+
+<P>
+This command allows you to see all the users that can be seen
+and the nodes to which they are connected. With the optional <em>node</em>,
+you can specify a particular node to look at.
+
+This command is normally abbreviated to: sh/c
+
+BE WARNED: the list that is returned can be VERY long
+
+<sect1>show/configuration/node (0)
+
+<P>
+<tt>
+<bf>show/configuration/node</bf> Show all the nodes connected
+</tt>
+
+<P>
+Show all the nodes connected locally and the nodes they have connected.
+
+<sect1>show/connect (1)
+
+<P>
+<tt>
+<bf>show/connect</bf> Show all the active connections
+</tt>
+
+<P>
+This command shows information on all the active connections known to
+the node. This command gives slightly more information than WHO.
+
<sect1>show/date (0)
<P>
SH/DXCC W on 20m info iota
</verb></tscreen>
+<sect1>sh/dxstats (0)
+
+<P>
+<tt>
+<bf>sh/dxstats</bf> Show the DX Statistics for last 31 days
+</tt>
+
+<P>
+Show the total DX spots for the last 31 days
+
+
<sect1>show/files (0)
<P>
<P>
A sysop can look at any filters that have been set.
+<sect1>show/hfstats (0)
+
+<P>
+<tt>
+<bf>show/hfstats</bf> Show the HF DX Statistics for last 31 days
+</tt>
+
+<P>
+Show the HF DX spots breakdown by band for the last 31 days
+
+<sect1>show/hftable (0)
+
+<P>
+<tt>
+<bf>show/hftable</bf> Show the HF DX Spotter Table for your country
+</tt>
+
+<P>
+Show the HF DX Spotter table for your country for the last 31 days
+
<sect1>show/hops (8)
<P>
indicating that you will have weak, fading circuits on top band and
80m but usable signals on 40m (about S3).
-inputing:-
+inputting:-
<tscreen><verb>
SH/MUF W 24
should be noted that the figures will probably not be very useful, nor
terrible accurate, but it is included for completeness.
+<sect1>show/newconfiguration (0)
+
+<P>
+<tt>
+<bf>show/newconfiguration [<node>]</bf> Show all the nodes and users visible
+</tt>
+
+<P>
+This command allows you to see all the users that can be seen
+and the nodes to which they are connected.
+
+This command produces essentially the same information as
+SHOW/CONFIGURATION except that it shows all the duplication of
+any routes that might be present It also uses a different format
+which may not take up quite as much space if you don't have any
+loops.
+
+BE WARNED: the list that is returned can be VERY long
+
+<sect1>show/newconfiguration/node (0)
+
+<P>
+<tt>
+<bf>show/newconfiguration/node</bf> Show all the nodes connected locally
+</tt>
+
+<P>
+Show all the nodes connected to this node in the new format.
+
<sect1>show/node (1)
<P>
and returns any information available for that callsign. This service
is provided for users of this software by http://www.qrz.com
+<sect1>show/registered (9)
+
+<P>
+<tt>
+<bf>show/registered [<prefix>[</bf> Show the registered users
+</tt>
+
<sect1>show/route (0)
<P>
then it will show UTC and UTC + the local offset (not including DST) at
the prefixes or callsigns that you specify.
+<sect1>show/vhfstats (0)
+
+<P>
+<tt>
+<bf>show/vhfstats</bf> Show the VHF DX Statistics for last 31 days
+</tt>
+
+<P>
+Show the VHF DX spots breakdown by band for the last 31 days
+
+<sect1>show/vhftable (0)
+
+<P>
+<tt>
+<bf>show/vhftable</bf> Show the VHF DX Spotter Table for your country
+</tt>
+
+<P>
+Show the VHF DX Spotter table for your country for the last 31 days
+
<sect1>show/wcy (0)
<P>
This command shows the internal status of a message and includes information
such as to whom it has been forwarded, its size, origin etc etc.
+<P>
+If no message number is given then the status of the message system is
+displayed.
+
+<sect1>stat/route_node (5)
+
+<P>
+<tt>
+<bf>stat/route_node <callsign></bf> Show the data in a Route::Node object
+</tt>
+
+<sect1>stat/route_user (5)
+
+<P>
+<tt>
+<bf>stat/route_user <callsign></bf> Show the data in a Route::User object
+</tt>
+
<sect1>stat/user (5)
<P>