<title>The DXSpider Administration Manual v1.48</title>
<author>Ian Maude, G0VGS, (ianmaude@btinternet.com)</author>
-<date>Version 1.48 August 2001 revision 1.1</date>
+<date>Version 1.49 November 2001 revision 1.0</date>
<abstract>
A reference for SysOps of the DXSpider DXCluster program.
of protection for these nodes.
<P>
-This is achieved by using filtering on a route basis. There is a
-default setting to help to protect the network, especially useful for new
-and inexperienced SysOps. The idea is simple. When Spider is started
-for the first time and a connection is made to or from another node,
-the default is to only send the nodes you already have that are in your
-own zone. For example, in the UK the default setting would be to send
-only UK nodes to any connection. This can be filtered further (down to
-a single node if needed) or expanded as required.
+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>
+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>.
-<sect1>Route Filters
+<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).
-<P>
-As mentioned in the introduction, a default setting exists. If this is
-all you want to use then that is fine, you have nothing else to do.
-However, if you want to make any alterations then you need to know
-a bit about filters.
+<sect1>Route Filters
-<P>
-It is possible to reset the default setting for node connections should
-you wish to do so, however this can be dangerous to the network unless
-you have some experience in how all this works.... be careful! It is
-also possible to change settings for one connection only. You can,
-therefore, have many different filters set dependent on the amount of
-node links you have.
+<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.
+
+<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.
<P>
I should at this stage give a little bit of background on filters. All
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.
-<sect1>The default_node filter
+<P>
+Anyway, without further discouragement, let me start the process
+of explanation.
+
+<sect1>The node_default filter
<P>
-As discussed previously, a default setting exists that only sends nodes
-from your own zone. This can be overridden by using the default_node
-filter option like this ...
+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>
+The generic commands are:-
<tscreen><verb>
-reject/route default_node <filter_option>
+reject/route node_default <filter_option>
or
-accept/route default_node <filter_option>
+accept/route node_default <filter_option>
</verb></tscreen>
-<P>
where filter_option is one of the following ...
<tscreen><verb>
call_dxcc <numbers>
call_itu <numbers>
call_zone <numbers>
-origin <prefixes>
-origin_dxcc <numbers>
-origin_itu <numbers>
-origin_zone <numbers>
+channel <prefixes>
+channel_dxcc <numbers>
+channel_itu <numbers>
+channel_zone <numbers>
</verb></tscreen>
-<P>
Please be careful if you alter this setting, it will affect
-<bf><it>ALL</it></bf> your links!
+<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>
+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>
+acc/route node_default call_dxcc 61,38
+acc/route node_default call gb7djk
+</verb></tscreen>
+
+GB7DJK uses the first of these. The DXCC countries can be obtained from the
+<it>show/prefix</it> command.
+
+<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>
+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>
+rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38
+</verb></tscreen>
+
+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>
+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>
+set/debug filter
+</verb></tscreen>
+
+After you have got tired of that, to put it back the way it was:-
+
+<tscreen><verb>
+unset/debug filter
+</verb></tscreen>
<sect1>General route filtering
</verb></tscreen>
<P>
-where filter_option is one of the following ...
+Here are some examples of route filters ...
<tscreen><verb>
-call <prefixes>
-call_dxcc <numbers>
-call_itu <numbers>
-call_zone <numbers>
-origin <prefixes>
-origin_dxcc <numbers>
-origin_itu <numbers>
-origin_zone <numbers>
+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>
-<P>
-Here are some examples of route filters ...
+In practice you will either be opening the default filter out for a
+partner by defining a specific filter for that callsign:-
+
+<tscreen><verb>
+acc/route gb7baa all
+acc/route gb7baa input all
+</verb></tscreen>
+
+or restricting it quite a lot, in fact making it very nearly like an
+<it>isolated</it> node, like this:-
<tscreen><verb>
-rej/route gb7djk call_dxcc 61,38 (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)
+acc/route pi4ehv-8 call gb7djk
+rej/route pi4ehv-8 input call_dxcc 61,38
</verb></tscreen>
+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.
+
+
<sect1>General filter rules
<P>
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>
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>
node and it will be routed across.
<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.
-
-<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 ....
-
-<tscreen><verb>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
-</verb></tscreen>
+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>
+In the first instance, in 1.48, the sysop can create, with their favorite
+text editor, files in the directory <em>/spider/scripts</em> which contain
+any legal command for a callsign or class of connection which will be executed
+at logon.
+
+<p>
+The filename is the callsign of the connection that you want the script to
+operate on, eg: <em>/spider/scripts/g1tlh</em>. The filenames are always in
+lower case on those architectures where this makes a difference.
+
+<p>
+In addition to the callsign specific scripts there are three others:-
+
+<tscreen><verb>
+startup
+user_default
+node_default
+</verb></tscreen>
+
+The <em>startup</em> script is executed immediately after all
+initialisation of the node is done, but before any connections are
+possible.
+
+<p>
+The <em>user_default</em> script is executed for every user that does
+<bf>NOT</bf> already have a specific script.
+
+<p>
+The <em>node_default</em> script is executed for every node that doesn't
+have a specific script.
+
+<p>
+There are a couple of examples in the <em>/spider/scripts</em> directory.
+
<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>
the setup. Many thanks to Fred Lloyd, the proprieter of
<htmlurl url="http://www.qrz.com" name="qrz.com"> for allowing this access.
+<sect1>Scripts
+
+<P>
+The directory /spider/scripts 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. 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>
+
+Secondly, it is used to store the login scripts for users. 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.
+
+<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
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>
expressions which are searched for in the fields targetted of each message.
If any of them match then that message is immediately deleted on receipt.
-<sect1>load/badwords (9)
-
-<P>
-<tt>
-<bf>load/badwords</bf> Reload the badwords file
-</tt>
-
-<P>
-Reload the /spider/data/badwords file if you have changed it manually whilst
-the cluster is running. This file contains a list of words which, if found
-on certain text portions of PC protocol, will cause those protocol frames
-to be rejected. It will all put out a message if any of these words are
-used on the announce, dx and talk commands. The words can be one or
-more on a line, lines starting with '#' are ignored.
-
<sect1>load/bands (9)
<P>
projects / spider.git / blobdiff