- 4. Databases
-
- 4.1 Creating databases
- 4.2 Importing databases
- 4.3 Checking available databases
- 4.4 Looking up databases
- 4.5 Removing databases
-
- 5. Information, files and useful programs
-
- 5.1 MOTD
- 5.2 Downtime message
- 5.3 Other text messages
- 5.4 The Aliases file
- 5.5 Console.pl
- 5.6 Updating kepler data
- 5.7 The QRZ callbook
-
- 6. CVS
-
- 7. The DXSpider command set
-
- 7.1 accept/announce (0)
- 7.2 accept/announce (extended for sysops) (8)
- 7.3 accept/route (8)
- 7.4 accept/spots (0)
- 7.5 accept/spots (extended for sysops) (8)
- 7.6 accept/wcy (0)
- 7.7 accept/wcy (extended for sysops) (8)
- 7.8 accept/wwv (0)
- 7.9 accept/wwv (extended for sysops) (8)
- 7.10 announce (0)
- 7.11 announce full (0)
- 7.12 announce sysop (5)
- 7.13 apropos (0)
- 7.14 bye (0)
- 7.15 catchup (5)
- 7.16 clear/spots (0)
- 7.17 connect (5)
- 7.18 dbavail (0)
- 7.19 dbcreate (9)
- 7.20 dbimport (9)
- 7.21 dbremove (9)
- 7.22 dbshow (0)
- 7.23 debug (9)
- 7.24 directory (0)
- 7.25 directory (extended for sysops) (5)
- 7.26 disconnect (8)
- 7.27 dx (0)
- 7.28 export (9)
- 7.29 export_users (9)
- 7.30 forward/latlong (8)
- 7.31 forward/opername (1)
- 7.32 help (0)
- 7.33 init (5)
- 7.34 kill (0)
- 7.35 kill (5)
- 7.36 kill full (5)
- 7.37 links (0)
- 7.38 load/aliases (9)
- 7.39 load/baddx (9)
- 7.40 load/badmsg (9)
- 7.41 load/badwords (9)
- 7.42 load/bands (9)
- 7.43 load/cmd_cache (9)
- 7.44 load/forward (9)
- 7.45 load/messages (9)
- 7.46 load/prefixes (9)
- 7.47 merge (5)
- 7.48 msg (9)
- 7.49 pc (8)
- 7.50 ping (1)
- 7.51 rcmd (1)
- 7.52 read (0)
- 7.53 read (extended for sysops) (5)
- 7.54 reject/announce
- 7.55 reject/announce (extended for sysops) (8)
- 7.56 reject/route (8)
- 7.57 reject/spots (0)
- 7.58 reject/spots (extended for sysops) (8)
- 7.59 reject/wcy (0)
- 7.60 reject/wcy (extended for sysops) (8)
- 7.61 reject/wwv (0)
- 7.62 reject/wwv (extended for sysops) (8)
- 7.63 reply (0)
- 7.64 send (0)
- 7.65 set/address (0)
- 7.66 set/announce (0)
- 7.67 set/arcluster (5)
- 7.68 set/baddx (8)
- 7.69 set/badnode (6)
- 7.70 set/badspotter (8)
- 7.71 set/beep (0)
- 7.72 set/bbs (5)
- 7.73 set/clx (5)
- 7.74 set/debug (9)
- 7.75 set/dx (0)
- 7.76 set/dxgrid (0)
- 7.77 set/dxnet (5)
- 7.78 set/echo (0)
- 7.79 set/here (0)
- 7.80 set/homenode (0)
- 7.81 set/hops (8)
- 7.82 set/isolate (9)
- 7.83 set/language (0)
- 7.84 set/location (0)
- 7.85 set/sys_location (9)
- 7.86 set/logininfo (0)
- 7.87 set/lockout (9)
- 7.88 set/name (0)
- 7.89 set/node (9)
- 7.90 set/obscount (9)
- 7.91 set/page (0)
- 7.92 set/password (9)
- 7.93 set/pinginterval (9)
- 7.94 set/privilege (9)
- 7.95 set/spider (5)
- 7.96 set/sys_qra (9)
- 7.97 set/qra (0)
- 7.98 set/qth (0)
- 7.99 set/talk (0)
- 7.100 set/wcy (0)
- 7.101 set/wwv (0)
- 7.102 set/wx (0)
- 7.103 show/baddx (1)
- 7.104 show/badnode (6)
- 7.105 show/badspotter (1)
- 7.106 show/configuration (0)
- 7.107 show/configuration/node (0)
- 7.108 show/connect (1)
- 7.109 show/date (0)
- 7.110 show/debug (9)
- 7.111 show/dx (0)
- 7.112 show/dxcc (0)
- 7.113 show/files (0)
- 7.114 show/filter (0)
- 7.115 show/filter (extended for sysops) (5)
- 7.116 show/hops (8)
- 7.117 show/isolate (1)
- 7.118 show/lockout (9)
- 7.119 show/log (8)
- 7.120 show/moon (0)
- 7.121 show/muf (0)
- 7.122 show/node (1)
- 7.123 show/prefix (0)
- 7.124 show/program (5)
- 7.125 show/qra (0)
- 7.126 show/qrz (0)
- 7.127 show/route (0)
- 7.128 show/satellite (0)
- 7.129 show/sun (0)
- 7.130 show/time (0)
- 7.131 show/wcy (0)
- 7.132 show/wwv (0)
- 7.133 shutdown (5)
- 7.134 spoof (9)
- 7.135 stat/db (5)
- 7.136 stat/channel (5)
- 7.137 stat/msg (5)
- 7.138 stat/route_node (5)
- 7.139 stat/route_user (5)
- 7.140 stat/user (5)
- 7.141 sysop (0)
- 7.142 talk (0)
- 7.143 type (0)
- 7.144 who (0)
- 7.145 wx (0)
- 7.146 wx (enhanced for sysops) (5)
+ 4. Scripts
+
+ 5. Databases
+
+ 5.1 Creating databases
+ 5.2 Importing databases
+ 5.3 Checking available databases
+ 5.4 Looking up databases
+ 5.5 Removing databases
+
+ 6. Information, files and useful programs
+
+ 6.1 MOTD
+ 6.2 Downtime message
+ 6.3 Other text messages
+ 6.4 The Aliases file
+ 6.5 Console.pl
+ 6.6 Updating kepler data
+ 6.7 The QRZ callbook
+
+ 7. CVS
+
+ 8. The DXSpider command set
+
+ 8.1 accept/announce (0)
+ 8.2 accept/announce (extended for sysops) (8)
+ 8.3 accept/route (8)
+ 8.4 accept/spots (0)
+ 8.5 accept/spots (extended for sysops) (8)
+ 8.6 accept/wcy (0)
+ 8.7 accept/wcy (extended for sysops) (8)
+ 8.8 accept/wwv (0)
+ 8.9 accept/wwv (extended for sysops) (8)
+ 8.10 announce (0)
+ 8.11 announce full (0)
+ 8.12 announce sysop (5)
+ 8.13 apropos (0)
+ 8.14 bye (0)
+ 8.15 catchup (5)
+ 8.16 clear/spots (0)
+ 8.17 connect (5)
+ 8.18 dbavail (0)
+ 8.19 dbcreate (9)
+ 8.20 dbimport (9)
+ 8.21 dbremove (9)
+ 8.22 dbshow (0)
+ 8.23 debug (9)
+ 8.24 directory (0)
+ 8.25 directory (extended for sysops) (5)
+ 8.26 disconnect (8)
+ 8.27 dx (0)
+ 8.28 export (9)
+ 8.29 export_users (9)
+ 8.30 forward/latlong (8)
+ 8.31 forward/opername (1)
+ 8.32 help (0)
+ 8.33 init (5)
+ 8.34 kill (0)
+ 8.35 kill (5)
+ 8.36 kill full (5)
+ 8.37 links (0)
+ 8.38 load/aliases (9)
+ 8.39 load/badmsg (9)
+ 8.40 load/bands (9)
+ 8.41 load/cmd_cache (9)
+ 8.42 load/forward (9)
+ 8.43 load/messages (9)
+ 8.44 load/prefixes (9)
+ 8.45 merge (5)
+ 8.46 msg (9)
+ 8.47 pc (8)
+ 8.48 ping (1)
+ 8.49 rcmd (1)
+ 8.50 read (0)
+ 8.51 read (extended for sysops) (5)
+ 8.52 reject/announce
+ 8.53 reject/announce (extended for sysops) (8)
+ 8.54 reject/route (8)
+ 8.55 reject/spots (0)
+ 8.56 reject/spots (extended for sysops) (8)
+ 8.57 reject/wcy (0)
+ 8.58 reject/wcy (extended for sysops) (8)
+ 8.59 reject/wwv (0)
+ 8.60 reject/wwv (extended for sysops) (8)
+ 8.61 reply (0)
+ 8.62 send (0)
+ 8.63 set/address (0)
+ 8.64 set/announce (0)
+ 8.65 set/arcluster (5)
+ 8.66 set/baddx (8)
+ 8.67 set/badnode (6)
+ 8.68 set/badspotter (8)
+ 8.69 set/beep (0)
+ 8.70 set/bbs (5)
+ 8.71 set/clx (5)
+ 8.72 set/debug (9)
+ 8.73 set/dx (0)
+ 8.74 set/dxgrid (0)
+ 8.75 set/dxnet (5)
+ 8.76 set/echo (0)
+ 8.77 set/here (0)
+ 8.78 set/homenode (0)
+ 8.79 set/hops (8)
+ 8.80 set/isolate (9)
+ 8.81 set/language (0)
+ 8.82 set/location (0)
+ 8.83 set/sys_location (9)
+ 8.84 set/logininfo (0)
+ 8.85 set/lockout (9)
+ 8.86 set/name (0)
+ 8.87 set/node (9)
+ 8.88 set/obscount (9)
+ 8.89 set/page (0)
+ 8.90 set/password (9)
+ 8.91 set/pinginterval (9)
+ 8.92 set/privilege (9)
+ 8.93 set/spider (5)
+ 8.94 set/sys_qra (9)
+ 8.95 set/qra (0)
+ 8.96 set/qth (0)
+ 8.97 set/talk (0)
+ 8.98 set/wcy (0)
+ 8.99 set/wwv (0)
+ 8.100 set/wx (0)
+ 8.101 show/baddx (1)
+ 8.102 show/badnode (6)
+ 8.103 show/badspotter (1)
+ 8.104 show/configuration (0)
+ 8.105 show/configuration/node (0)
+ 8.106 show/connect (1)
+ 8.107 show/date (0)
+ 8.108 show/debug (9)
+ 8.109 show/dx (0)
+ 8.110 show/dxcc (0)
+ 8.111 show/files (0)
+ 8.112 show/filter (0)
+ 8.113 show/filter (extended for sysops) (5)
+ 8.114 show/hops (8)
+ 8.115 show/isolate (1)
+ 8.116 show/lockout (9)
+ 8.117 show/log (8)
+ 8.118 show/moon (0)
+ 8.119 show/muf (0)
+ 8.120 show/node (1)
+ 8.121 show/prefix (0)
+ 8.122 show/program (5)
+ 8.123 show/qra (0)
+ 8.124 show/qrz (0)
+ 8.125 show/route (0)
+ 8.126 show/satellite (0)
+ 8.127 show/sun (0)
+ 8.128 show/time (0)
+ 8.129 show/wcy (0)
+ 8.130 show/wwv (0)
+ 8.131 shutdown (5)
+ 8.132 spoof (9)
+ 8.133 stat/db (5)
+ 8.134 stat/channel (5)
+ 8.135 stat/msg (5)
+ 8.136 stat/route_node (5)
+ 8.137 stat/route_user (5)
+ 8.138 stat/user (5)
+ 8.139 sysop (0)
+ 8.140 talk (0)
+ 8.141 type (0)
+ 8.142 who (0)
+ 8.143 wx (0)
+ 8.144 wx (enhanced for sysops) (5)
- 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
+ isolation. This is similar to what in other systems such as clx, is
+ called passive mode. A more detailed explanation of isolation is given
+ further below. This system is still available and, for simple
+ networks, is probably all that you need.
+ The new functionality introduced in version 1.48 allows filtering the
+ node and user protocol frames on a "per interface" basis. We call this
+ route filtering. This is used instead of isolation.
+
+
+ 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 rcmd command).
+
- 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.
+ 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.
+
+
+ The first thing that you must do is determine whether you need to use
+ route filtering at all. If you are a "normal" node with two or three
+ partners and you arranged in an "official" non-looping tree type
+ network, then you do not need to do route filtering and you will feel
+ a lot better for not getting involved. If you are successfully using
+ isolation then you also probably don't need to use route filtering.
+
+
+ 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.
- 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.
+ 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.
+ 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.
+
+
+ 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:-
+
+
+
+ set/debug filter
+
+
+
+
+ After you have got tired of that, to put it back the way it was:-
+
+
+
+ unset/debug filter
+
+
+
+
+
+ 1.4. General route filtering
+
+ Exactly the same rules apply for general route filtering. You would
+ use either an accept filter or a reject filter like this ...
+ reject/route <node_call> <filter_option>
+
+ or
+
+ accept/route <node_call> <filter_option>
+ In practice you will either be opening the default filter out for a
+ partner by defining a specific filter for that callsign:-
+
+
+
+ acc/route gb7baa all
+ acc/route gb7baa input all
+
+
+
+
+ or restricting it quite a lot, in fact making it very nearly like an
+ isolated node, like this:-
+
+
+
+ acc/route pi4ehv-8 call gb7djk
+ rej/route pi4ehv-8 input call_dxcc 61,38
+
+
+
+
+ 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).
+
+
+ It is possible to write much more complex rules, there are up to 10
+ accept/reject pairs per callsign per filter. For more information see
+ the next section.
+
+
-
-
-
-
-
-
-
-
-
-
-
-
- #
- # 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,
- },
- };
-
-
-
-
-
- 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.
-
-
- You can alter this file at any time, including whilst the cluster is
- running. If you alter the file during runtime, the command load/hops
- will bring your changes into effect.
-
-
-
- 1.11. Isolating networks
+ 1.12. Isolating networks
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
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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- #
- # this is an example message forwarding file for the system
- #
- # The format of each line is as follows
- #
- # type to/from/at pattern action destinations
- # P/B/F T/F/A regex I/F [ call [, call ...] ]
- #
- # type: P - private, B - bulletin (msg), F - file (ak1a bull)
- # to/from/at: T - to field, F - from field, A - home bbs, O - origin
- # pattern: a perl regex on the field requested
- # action: I - ignore, F - forward
- # destinations: a reference to an array containing node callsigns
- #
- # if it is non-private and isn't in here then it won't get forwarded
- #
- # Currently only type B msgs are affected by this code.
- #
- # The list is read from the top down, the first pattern that matches
- # causes the action to be taken.
- #
- # The pattern can be undef or 0 in which case it will always be selected
- # for the action specified
- #
- # If the BBS list is undef or 0 and the action is 'F' (and it matches the
- # pattern) then it will always be forwarded to every node that doesn't have
- # it (I strongly recommend you don't use this unless you REALLY mean it, if
- # you allow a new link with this on EVERY bull will be forwarded immediately
- # on first connection)
- #
-
- package DXMsg;
-
- @forward = (
- );
+ #
+ # this is an example message forwarding file for the system
+ #
+ # The format of each line is as follows
+ #
+ # type to/from/at pattern action destinations
+ # P/B/F T/F/A regex I/F [ call [, call ...] ]
+ #
+ # type: P - private, B - bulletin (msg), F - file (ak1a bull)
+ # to/from/at: T - to field, F - from field, A - home bbs, O - origin
+ # pattern: a perl regex on the field requested
+ # action: I - ignore, F - forward
+ # destinations: a reference to an array containing node callsigns
+ #
+ # if it is non-private and isn't in here then it won't get forwarded
+ #
+ # Currently only type B msgs are affected by this code.
+ #
+ # The list is read from the top down, the first pattern that matches
+ # causes the action to be taken.
+ #
+ # The pattern can be undef or 0 in which case it will always be selected
+ # for the action specified
+ #
+ # If the BBS list is undef or 0 and the action is 'F' (and it matches the
+ # pattern) then it will always be forwarded to every node that doesn't have
+ # it (I strongly recommend you don't use this unless you REALLY mean it, if
+ # you allow a new link with this on EVERY bull will be forwarded immediately
+ # on first connection)
+ #
+
+ package DXMsg;
+
+ @forward = (
+ );
-
-
-
-
-
-
-
-
- MSG TO <msgno> <call> - change TO callsign to <call>
- MSG FRom <msgno> <call> - change FROM callsign to <call>
- MSG PRrivate <msgno> - set private flag
- MSG NOPRrivate <msgno> - unset private flag
- MSG RR <msgno> - set RR flag
- MSG NORR <msgno> - unset RR flag
- MSG KEep <msgno> - set the keep flag (message won't be deleted ever)
- MSG NOKEep <msgno> - unset the keep flag
- MSG SUbject <msgno> <new> - change the subject to <new>
- MSG WAittime <msgno> - remove any waiting time for this message
- MSG NOREad <msgno> - mark message as unread
- MSG REad <msgno> - mark message as read
- MSG QUeue - queue any outstanding bulletins
- MSG QUeue 1 - queue any outstanding private messages
+ MSG TO <msgno> <call> - change TO callsign to <call>
+ MSG FRom <msgno> <call> - change FROM callsign to <call>
+ MSG PRrivate <msgno> - set private flag
+ MSG NOPRrivate <msgno> - unset private flag
+ MSG RR <msgno> - set RR flag
+ MSG NORR <msgno> - unset RR flag
+ MSG KEep <msgno> - set the keep flag (message won't be deleted ever)
+ MSG NOKEep <msgno> - unset the keep flag
+ MSG SUbject <msgno> <new> - change the subject to <new>
+ MSG WAittime <msgno> - remove any waiting time for this message
+ MSG NOREad <msgno> - mark message as unread
+ MSG REad <msgno> - mark message as read
+ MSG QUeue - queue any outstanding bulletins
+ MSG QUeue 1 - queue any outstanding private messages
+ 4. Scripts
+
+ From 1.48 onwards it will become increasingly possible to control
+ DXSpider's operation with scripts of various kinds.
+
+
+ In the first instance, in 1.48, the sysop can create, with their
+ favorite text editor, files in the directory /spider/scripts which
+ contain any legal command for a callsign or class of connection which
+ will be executed at logon.
+
+
+
+ The filename is the callsign of the connection that you want the
+ script to operate on, eg: /spider/scripts/g1tlh. The filenames are
+ always in lower case on those architectures where this makes a
+ difference.
+
+
+ In addition to the callsign specific scripts there are three others:-
+
+
+
+
+
+
+ startup
+ user_default
+ node_default
+
+
+
+
+ The startup script is executed immediately after all initialisation of
+ the node is done, but before any connections are possible.
+
+
+ The user_default script is executed for every user that does NOT
+ already have a specific script.
+
+
+ The node_default script is executed for every node that doesn't have a
+ specific script.
+
+
+ There are a couple of examples in the /spider/scripts directory.
+
+
+ 5. Databases
- 7.41. load/badwords (9)
-
- load/badwords Reload the badwords file
-
-
- 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.
-
-
- 7.42. load/bands (9)