<!-- Title information -->
-<title>The DXSpider Administration Manual v1.48</title>
-<author>Ian Maude, G0VGS, (ianmaude@btinternet.com)</author>
-<date>Version 1.49 November 2001 revision 1.0</date>
+<title>The DXSpider Administration Manual v1.50</title>
+<author>Ian Maude, G0VGS, (g0vgs@gb7mbc.net)</author>
+<date>July 2002 revision 0.1</date>
<abstract>
A reference for SysOps of the DXSpider DXCluster program.
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
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.
+You can show what hops have been set using the <em>show/hops</em> command.
<sect1>Isolating networks
<P>
To force the cluster to reread the file use load/forward
+<P>
+NB: If a user tries to send mail to a bulletin address that does not exist
+in this file, they will get an error.
<sect1>The msg command
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 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.
-<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.
+<tscreen><verb>
+#
+# startup script example
+#
+# set maximum no of spots allowed to 100
+# set/var $Spot::maxspots = 100
+#
+# Set registration on
+# set/var $main::reqreg = 1
+#
+# Set passwords on
+# set/var $main::passwdreq = 1
+#
+</verb></tscreen>
-<p>
-In addition to the callsign specific scripts there are three others:-
+<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.
+
+<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>
-startup
-user_default
-node_default
+#
+# G0FYD
+#
+blank +
+sh/wwv 3
+blank +
+sh/dx
+blank +
+t g0jhc You abt?
+blank +
</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.
+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>
-The <em>node_default</em> script is executed for every node that doesn't
-have a specific script.
+<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>
-There are a couple of examples in the <em>/spider/scripts</em> directory.
+<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
<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 ...
-
-<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!)
+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.
-# 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.
-<sect1>Scripts
+<sect1>Connecting logging programs
<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.
+There appear to be very few logging programs out there that support telnet
+especially the popular ones like LogEQF, Turbolog etc. This can make it
+difficult to connect to your own cluster!
+The way to do it is to make the logging program think it has a TNC attached
+to a com port on the logging PC and 'push' a linux login out to it.
+This is achieved very simply by the use of <em>agetty</em>.
+
+<P>
+All that is required is to add a line in /etc/inittab to have the client
+ready for a connection on the com port of your choice. Remember that in
+Linux, the com ports start at ttyS0 for com1, ttyS1 for com2 etc.
<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
-#
+c4:2345:respawn:/sbin/agetty -L 9600 ttyS1
</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.
+<P>
+Add this after the standard runlevel lines in /etc/inittab. The above
+line works on ttyS1 (com2). Now as root, issue the command <em>telinit q</em>
+and it should be ready for connection. All that is required is a 3 wire
+serial lead (tx, rx and signal ground). Tell you logging program to use
+8n1 at 9600 baud and you should see a Linux login prompt. Login as normal
+and then telnet from there to the cluster.
+
+<sect>Java Web applet
+
+<P>
+In the spider tree will be a directory <em>spider-web</em>. This is a
+neat little java web applet that can be run from a website. The applet
+must run on the same machine as the cluster. The included README file is
+shown below.
+
+<P>
+I should comment here that the applet is precompiled, that is, ready to go.
+It was compiled using JDK1.3.1. If your version is earlier than this then it
+may not work. Should that be the case you need to recompile or update your
+JDK. To recompile do the following ...
<tscreen><verb>
-#
-# G0FYD
-#
-blank +
-sh/wwv 3
-blank +
-sh/dx
-blank +
-t g0jhc You abt?
-blank +
+cd /spider/spider-web
+rm *.class
+/usr/bin/javac spiderclient.java
</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.
+<P>
+I have used /usr/bin/javac as an example, your path to javac may be different.
+
+<verb>
+Spider-WEB v0.6b
+
+Completely based on a clx web client written in Java by dl6dbh
+(ftp://clx.muc.de/pub/clx/clx-java_10130001.tgz)
+
+The webserver has to run on the same machine as your DxSpider software!
+
+It is assumed that you have Java installed. You need JDK1.3.1 at least.
+
+Installation instructions (Performed as root):
+
+Put all the files in the spider-web directory into a newly created directory
+under the DocumentRoot of your websever for instance 'client'. In my case
+this is: /home/httpd/html/client/ although ymmv. For Suse the correct
+path should be /usr/local/httpd/htdocs/client/ for example.
+
+Move spider.cgi to the cgi-bin directory of your webserver, in my case that is
+/home/httpd/cgi-bin/ although ymmv. For Suse the correct path should be
+/usr/local/httpd/cgi-bin/ for example.
+
+Change the permissions of the files to ensure they are correct, obviously you
+will need to use the correct path the the files according to your system:
+
+chmod 755 /home/httpd/html/cgi-bin/spider.cgi
+chmod -R 755 /home/httpd/html/client/
+
+By default the spider.cgi script should pick up your hostname (As long as this
+is set correctly). If it does not or your hostname differs from the name that
+you attach to the public address that you are using, then edit spider.cgi :
+
+# Uncomment and set the hostname manually here if the above fails.
+# $HOSTNAME = "gb7mbc.spoo.org" ;
+$PORT = "8000" ;
+
+'HOSTNAME' is the hostname of your cluster.
+
+'PORT' is the portnumber that you use to connect to your DxSpider via
+telnet (see Listeners.pm)
+
+NOTE: If you can start the console but cannot connect to the cluster from it,
+then it is possible that the machine you are on cannot resolve the hostname of
+your cluster machine. If this is the case, you need to set your hostname
+manually as above.
+
+You also need to set the $NODECALL variable. This prints the name of your
+choosing (probably your cluster callsign) on the html page.
+
+You now can connect to Spider-Web via http://yourserver/cgi-bin/spider.cgi
+</verb>
<sect>Security
<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>
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)
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>demonstrate (9)
+
+<P>
+<tt>
+<bf>demonstrate <call> <command></bf> Demonstrate a command to another user
+</tt>
+
+<P>
+This command is provided so that sysops can demonstrate commands to
+other users. It runs a command as though that user had typed it in and
+then sends the output to that user, together with the command that
+caused it.
+
+<tscreen><verb>
+ DEMO g7brn sh/dx iota oc209
+ DEMO g1tlh set/here
+</verb></tscreen>
+
+Note that this command is similar to SPOOF and will have the same side
+effects. Commands are run at the privilege of the user which is being
+demonstrated to.
+
<sect1>directory (0)
<P>
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>
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 bad words table
+</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>
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>
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>
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>
projects / spider.git / blobdiff