-<!doctype linuxdoc system>
-
-<article>
-
-<!-- Title information -->
-
-<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.
-</abstract>
-
-<!-- Table of contents -->
-<toc>
-
-<!-- Begin the document -->
-
-<sect>Routing and Filtering
-
-<sect1>Introduction
-
-<P>
-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>
-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>.
-
-<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).
-
-<sect1>Route Filters
-
-<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
-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.
-
-<P>
-Anyway, without further discouragement, let me start the process
-of explanation.
-
-<sect1>The node_default filter
-
-<P>
-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 node_default <filter_option>
-
-or
-
-accept/route node_default <filter_option>
-</verb></tscreen>
-
-where filter_option is one of the following ...
-
-<tscreen><verb>
-call <prefixes>
-call_dxcc <numbers>
-call_itu <numbers>
-call_zone <numbers>
-channel <prefixes>
-channel_dxcc <numbers>
-channel_itu <numbers>
-channel_zone <numbers>
-</verb></tscreen>
-
-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>
-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
-
-<P>
-Exactly the same rules apply for general route filtering. You would
-use either an accept filter or a reject filter like this ...
-
-<tscreen><verb>
-reject/route <node_call> <filter_option>
-
-or
-
-accept/route <node_call> <filter_option>
-</verb></tscreen>
-
-<P>
-Here are some examples of route filters ...
-
-<tscreen><verb>
-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>
-
-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>
-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>
-Upto v1.44 it was not possible for the user to set their own filters. From
-v1.45 though that has all changed. It is now possible to set filters for just
-about anything you wish. If you have just updated from an older version of
-DXSpider you will need to update your new filters. You do not need to do
-anything with your old filters, they will be renamed as you update.
-
-<P>
-There are 3 basic commands involved in setting and manipulating filters. These
-are <em>accept</em>, <em>reject</em> and <em>clear</em>. First we will look
-generally at filtering. There are a number of things you can filter in the
-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
-up to 10 lines in it. You do this using, for example ...
-
-<tscreen><verb>
-accept/spots .....
-reject/spots .....
-</verb></tscreen>
-
-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. They are ...
-
-<tscreen><verb>
-clear/spots 1
-clear/spots all
-</verb></tscreen>
-
-There is clear/xxxx command for each type of filter.
-
-<P>
-and you can check that your filters have worked by the command ...
-
-<tscreen><verb>
-show/filter
-</verb></tscreen>
-
-<P>
-For now we are going to use spots for the examples, but you can apply the same
-principles to all types of filter.
-
-<sect1>Types of filter
-
-<P>
-There are two main types of filter, <em>accept</em> or <em>reject</em>. You
-can use either to achieve the result you want dependent on your own preference
-and which is more simple to do. It is pointless writing 8 lines of reject
-filters when 1 accept filter would do the same thing! 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 take it)
-
-<P>
-If you specify reject filters, then any lines that arrive that match the filter
-will be dumped but all else will be accepted. If you use an accept filter,
-then ONLY the lines in the filter will be accepted and all else will be dumped.
-For example if you have a single line <em>accept</em> filter ...
-
-<tscreen><verb>
-accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-</verb></tscreen>
-
-then you will <em>ONLY</em> get VHF spots <em>from</em> or <em>to</em> CQ zones
-14, 15 and 16.
-
-<P>
-If you set a reject filter like this ...
-
-<tscreen><verb>
-reject/spots on hf/cw
-</verb></tscreen>
-
-Then you will get everything <em>EXCEPT</em> HF CW spots. You could make this
-single filter even more flexible. For example, if you are interested in IOTA
-and will work it even on CW even though normally you are not interested in
-CW, then you could say ...
-
-<tscreen><verb>
-reject/spots on hf/cw and not info iota
-</verb></tscreen>
-
-But in that case you might only be interested in iota and say:-
-
-<tscreen><verb>
-accept/spots not on hf/cw or info iota
-</verb></tscreen>
-
-which achieves exactly the same thing. You should choose one or the other
-until you are comfortable with the way it works. You can mix them if you
-wish (actually you can have an accept AND a reject on the same line) but
-don't attempt this until you are sure you know what you are doing!
-
-<P>
-You can arrange your filter lines into logical units, either for your own
-understanding or simply convenience. Here is an example ...
-
-<tscreen><verb>
-reject/spots 1 on hf/cw
-reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)
-</verb></tscreen>
-
-What this does is to ignore all HF CW spots and also rejects any spots on VHF
-which don't either originate or spot someone in Europe.
-
-<P>
-This is an example where you would use a line number (1 and 2 in this case), if
-you leave the digit out, the system assumes '1'. Digits '0'-'9' are available.
-This make it easier to see just what filters you have set. It also makes it
-more simple to remove individual filters, during a contest for example.
-
-<P>
-You will notice in the above example that the second line has brackets. Look
-at the line logically. You can see there are 2 separate sections to it. We
-are saying reject spots that are VHF or above <em>APART</em> from those in
-zones 14, 15 and 16 (either spotted there or originated there). If you did
-not have the brackets to separate the 2 sections, then Spider would read it
-logically from the front and see a different expression entirely ...
-
-<tscreen><verb>
-(on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16
-</verb></tscreen>
-
-The simple way to remember this is, if you use OR - use brackets. Whilst we are
-here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'.
-
-As mentioned earlier, setting several filters can be more flexible than
-simply setting one complex one. Doing it in this way means that if you want
-to alter your filter you can just redefine or remove one or more lines of it or
-one line. For example ...
-
-<tscreen><verb>
-reject/spots 1 on hf/ssb
-</verb></tscreen>
-
-would redefine our earlier example, or
-
-<tscreen><verb>
-clear/spots 1
-</verb></tscreen>
-
-To remove all the filter lines in the spot filter ...
-
-<tscreen><verb>
-clear/spots all
-</verb></tscreen>
-
-<sect1>Filter options
-
-<P>
-You can filter in several different ways. The options are listed in the
-various helpfiles for accept, reject and filter.
-
-<sect1>Default filters
-
-<P>
-Sometimes all that is needed is a general rule for node connects. This can
-be done with a node_default filter. This rule will always be followed, even
-if the link is isolated, unless another filter is set specifically. Default
-rules can be set for nodes and users. They can be set for spots, announces,
-WWV and WCY. They can also be used for hops. An example might look like
-this ...
-
-<tscreen><verb>
-accept/spot node_default by_zone 14,15,16,20,33
-set/hops node_default spot 50
-</verb></tscreen>
-
-This filter is for spots only, you could set others for announce, WWV and WCY.
-This filter would work for ALL nodes unless a specific filter is written to
-override it for a particular node. You can also set a user_default should
-you require. It is important to note that default filters should be
-considered to be "connected". By this I mean that should you override the
-default filter for spots, you need to add a rule for the hops for spots also.
-
-<sect1>Advanced filtering
-
-<P>
-Once you are happy with the results you get, you may like to experiment.
-
-<P>
-The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU
-can be written with a mixed filter, for example ...
-
-<tscreen><verb>
-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)
-</verb></tscreen>
-
-Note that the first filter has not been specified with a number. This will
-automatically be assumed to be number 1. In this case, we have said <em>reject all
-HF spots in the CW section of the bands but accept all others at HF. Also
-accept anything in VHF and above spotted in or by operators in the zones
-14, 15 and 16</em>. Each filter slot actually has a 'reject' slot and
-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.
-
-<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 show 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
-
-<sect1>Filtering Mail
-
-<P>
-In the /spider/msg directory you will find a file called badmsg.pl.issue. Rename
-this to badmsg.pl and edit the file. The original looks something like this ....
-
-<tscreen><verb>
-
-# the list of regexes for messages that we won't store having
-# received them (bear in mind that we must receive them fully before
-# we can bin them)
-
-
-# The format of each line is as follows
-
-# type source pattern
-# P/B/F T/F/O/S regex
-
-# type: P - private, B - bulletin (msg), F - file (ak1a bull)
-# source: T - to field, F - from field, O - origin, S - subject
-# pattern: a perl regex on the field requested
-
-# Currently only type B and P 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
-
-
-
-package DXMsg;
-
-@badmsg = (
-'B', 'T', 'SALE',
-'B', 'T', 'WANTED',
-'B', 'S', 'WANTED',
-'B', 'S', 'SALE',
-'B', 'S', 'WTB',
-'B', 'S', 'WTS',
-'B', 'T', 'FS',
-);
-</verb></tscreen>
-
-<P>
-I think this is fairly self explanatory. It is simply a list of subject
-headers that we do not want to pass on to either the users of the cluster or
-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 words from text fields in Announce, Talk and DX spots
-
-<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.
-
-<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.
-
-<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.
-
-<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.
-
-<p>
-There are a set of commands which allow the sysop to control whether a
-spot continues:-
-
-<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:
-
-<tscreen><verb>
-set/badnode gb7djk gb7dxc
-</verb></tscreen>
-
-a bad spotter:
-
-<tscreen><verb>
-set/badspotter b0mb p1rat nocall
-</verb></tscreen>
-
-and some bad dx:
-
-<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
-
-<P>
-DXSpider deals seamlessly with standard AK1A type mail. It supports both
-personal and bulletin mail and the sysop has additional commands to ensure
-that mail gets to where it is meant. DXSpider will send mail almost
-immediately, assuming that the target is on line. However, only one
-mail message is dealt with at any one time. If a mail message is already
-being sent or recieved, then the new message will be queued until it has
-finished.
-
-The cluster mail is automatically deleted after 30 days unless the sysop
-sets the "keep" flag using the <em>msg</em> command.
-
-<sect1>Personal mail
-
-<P>
-Personal mail is sent using the <em>sp</em> command. This is actually the
-default method of sending mail and so a simple <em>s</em> for send will do.
-A full list of the send commands and options is in the <em>command set</em>
-section, so I will not duplicate them here.
-
-<sect1>Bulletin mail
-
-<P>
-Bulletin mail is sent by using the <em>sb</em> command. This is one of the
-most common mistakes users make when sending mail. They send a bulletin
-mail with <em>s</em> or <em>sp</em> instead of <em>sb</em> and of course
-the message never leaves the cluster. This can be rectified by the sysop
-by using the <em>msg</em> command.
-
-<P>Bulletin addresses can be set using the Forward.pl file.
-
-<sect1>Forward.pl
-
-<P>
-DXSpider receives all and any mail sent to it without any alterations needed
-in files. Because personal and bulletin mail are treated differently, there
-is no need for a list of accepted bulletin addresses. It is necessary, however,
-to tell the program which links accept which bulletins. For example, it is
-pointless sending bulletins addresses to "UK" to any links other than UK
-ones. The file that does this is called forward.pl and lives in /spider/msg.
-At default, like other spider files it is named forward.pl.issue. Rename it
-to forward.pl and edit the file to match your requirements.
-The format is below ...
-
-<tscreen><verb>
-#
-# 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 = (
-'B', 'T', 'LOCAL', 'F', [ qw(GB7MBC) ],
-'B', 'T', 'ALL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
-'B', 'T', 'UK', 'F', [ qw(GB7BAA GB7ADX) ],
-'B', 'T', 'QSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
-'B', 'T', 'QSLINF', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
-'B', 'T', 'DX', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
-'B', 'T', 'DXINFO', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
-'B', 'T', 'DXNEWS', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
-'B', 'T', 'DXQSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
-'B', 'T', 'SYSOP', 'F', [ qw(GB7BAA GB7ADX) ],
-'B', 'T', '50MHZ', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
-);
-</verb></tscreen>
-
-Simply insert a bulletin address and state in the brackets where you wish
-that mail to go. For example, you can see here that mail sent to "UK" will
-only be sent to the UK links and not to PA4AB-14.
-
-<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
-
-<P>
-The <em>msg</em> command is a very powerful and flexible tool for the
-sysop. It allows the sysop to alter to and from fields and make other
-changes to manage the cluster mail.
-
-Here is a full list of the various options ...
-
-<tscreen><verb>
- 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
-</verb></tscreen>
-
-These commands are simply typed from within the cluster as the sysop user.
-
-<sect1>Message status
-
-<P>
-You can check on a message from within the cluster by using the command
-<em>stat/msg</em>. This will give you additional information on the
-message number including which nodes have received it, which node it
-was received from and when etc. Here is an example of the output of
-the command ...
-
-<tscreen><verb>
-G0VGS de GB7MBC 28-Jan-2001 1308Z >
-stat/msg 6869
- From: GB7DJK
- Msg Time: 26-Jan-2001 1302Z
- Msgno: 6869
- Origin: GB7DJK
- Size: 8012
- Subject: AMSAT 2line KEPS 01025.AMSAT
- To: UK
-Got it Nodes: GB7BAA, GB7ADX
- Private: 0
-Read Confirm: 0
- Times read: 0
-G0VGS de GB7MBC 28-Jan-2001 1308Z >
-</verb></tscreen>
-
-<sect1>Filtering mail
-
-<P>
-This is described in the section on <em>Other filters</em> so I will not
-duplicate it here.
-
-<sect1>Distribution lists
-
-<P>
-Distribution lists are simply a list of users to send certain types of
-mail to. An example of this is mail you only wish to send to other
-sysops. In /spider/msg there is a directory called <em>distro</em>. You
-put any distibution lists in here. For example, here is a file called
-SYSOP.pl that caters for the UK sysops.
-
-<tscreen><verb>
-qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX
- GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH
- GB7DXK GB7DXI GB7DXS)
-</verb></tscreen>
-
-Any mail sent to "sysop" would only be sent to the callsigns in this list.
-
-<sect1>BBS interface
-
-<P>
-Spider provides a simple BBS interface. No input is required from the sysop
-of the cluster at all. The BBS simply sets the cluster as a BBS and pushes
-any required mail to the cluster. No mail can flow from Spider to the BBS,
-the interface is one-way.
-
-<P>
-Please be careful not to flood the cluster network with unnecessary 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 = 100
-#
-# 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.
-
-<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>
-Spider allows the creation of local or remote databases. It supports
-chained databases, allowing several different databases to be scanned
-with one simple command. Importing of databases is limited at present
-to the standard AK1A databases such as OBLAST and the DB0SDX QSL
-database but will expand with time.
-
-<sect1>Creating databases
-
-<P>
-Creating a database could not be more simple. All the commands are
-sent from the cluster prompt as the <em>sysop</em> user.
-
-To create a database you use the command <em>dbcreate</em>. It can
-be used in 3 different ways like so ..
-
-<tscreen><verb>
-dbcreate <name>
-</verb></tscreen>
-
-To simply create a database locally, you just tell the command the
-name of the database. This does not create the actual database, it
-simply defines it to say that it exists.
-
-<tscreen><verb>
-dbcreate <name> chain <name> [<name>...]
-</verb></tscreen>
-
-This creates a chained database entry. The first database will be
-scanned, then the second, the third etc...
-
-<tscreen><verb>
-dbcreate <name> remote <name>
-</verb></tscreen>
-
-This creates a remote entry. the first name field is the database
-name at the remote node, then the remote switch, then the actual
-node_call of the remote node, for example...
-
-<tscreen><verb>
-dbcreate buckmaster remote gb7dxc
-</verb></tscreen>
-
-Remote databases cannot be chained, however, the last database in a
-chain can be a remote database.
-
-<sect1>Importing databases
-
-<P>
-The only databases that Spider can currently import are the standard
-AK1A databases such as OBLAST or the DB0SDX qsl and address database.
-This will be added to with time.
-
-To import such a database, first put the file somewhere useful like /tmp
-and then issue the following command ...
-
-<tscreen><verb>
-dbimport oblast /tmp/OBLAST.FUL
-</verb></tscreen>
-
-This will update the existing local oblast database or create it if
-it does not exist.
-
-<sect1>Checking available databases
-
-<P>
-Once a database is created, you will want to check that it has been
-added. To do this use the <em>dbavail</em> command. This will
-output the available databases. For example ...
-
-<tscreen><verb>
-dbavail
-DB Name Location Chain
-qsl Local
-buck GB7ADX
-hftest GB7DXM
-G0VGS de GB7MBC 3-Feb-2001 1925Z >
-</verb></tscreen>
-
-<sect1>Looking up databases
-
-<P>
-To look for information in a defined database, simply use the <em>dbshow</em>
-command, for example ...
-
-<tscreen><verb>
-dbshow buckmaster G0YLM
-</verb></tscreen>
-
-will show the information for the callsign G0YLM from the buckmaster
-database if it exists. To make things more standard for the users
-you can add an entry in the Aliases file so that it looks like a standard
-<em>show</em> command like this ...
-
-<tscreen><verb>
-'^sh\w*/buc', 'dbshow buckmaster', 'dbshow',
-</verb></tscreen>
-
-Now you can simply use show/buckmaster or an abreviation.
-
-<sect1>Removing databases
-
-<P>
-To delete an existing database you use the <em>dbremove</em> command.
-For example ...
-
-<tscreen><verb>
-dbremove oblast
-</verb></tscreen>
-
-would remove the oblast database and its associated datafile from the
-system. There are no warnings or recovery possible from this command.
-If you remove a database it ceases to exist and would have to be created
-from scratch if you still required it.
-
-<sect>Information, files and useful programs
-
-<sect1>MOTD
-
-<P>
-One of the more important things a cluster sysop needs to do is to get
-information to his users. The simplest way to do this is to have a banner
-that is sent to the user on login. This is know as a "message of the day"
-or "motd". To set this up, simply create a file in /spider/data called motd
-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>
-If for any reason the cluster is down, maybe for upgrade or maintenance but
-the machine is still running, a message can be sent to the user advising them
-of the fact. This message lives in the /spider/data directory and is called
-"offline". Simply create the file and edit it to say whatever you wish.
-This file will be sent to a user attempting to log into the cluster when
-DXSpider is not actually running.
-
-<sect1>Other text messages
-
-<P>
-You can set other text messages to be read by the user if they input the file
-name. This could be for news items or maybe information for new users.
-To set this up, make a directory under /spider called <em>packclus</em>.
-Under this directory you can create files called <em>news</em> or <em>newuser</em>
-for example. In fact you can create files with any names you like. These can
-be listed by the user with the command ....
-
-<tscreen><verb>
-show/files
-</verb></tscreen>
-
-They can be read by the user by typing the command ....
-
-<tscreen><verb>
-type news
-</verb></tscreen>
-
-If the file they want to read is called <em>news</em>. You could also set
-an alias for this in the Alias file to allow them just to type <em>news</em>
-
-<P>
-You can also store other information in this directory, either directly or
-nested under directories. One use for this would be to store DX bulletins
-such as the OPDX bulletins. These can be listed and read by the user.
-To keep things tidy, make a directory under /spider/packclus called
-<em>bulletin</em>. Now copy any OPDX or similar bulletins into it. These
-can be listed by the user in the same way as above using the <em>show/files</em>
-command with an extension for the bulletin directory you have just created,
-like this ....
-
-<tscreen><verb>
-show/files bulletin
-</verb></tscreen>
-
-<P>
-An example would look like this ....
-
-<tscreen><verb>
-sh/files
-bulletin DIR 20-Dec-1999 1715Z news 1602 14-Dec-1999 1330Z
-</verb></tscreen>
-
-You can see that in the files area (basically the packclus directory) there is a
-file called <em>news</em> and a directory called <em>bulletin</em>. You can
-also see that dates they were created. In the case of the file <em>news</em>,
-you can also see the time it was last modified, a good clue as to whether the
-file has been updated since you last read it. To read the file called
-<em>news</em> you would simply issue the command ....
-
-<tscreen><verb>
-type news
-</verb></tscreen>
-
-To look what is in the bulletin directory you issue the command ....
-
-<tscreen><verb>
-show/files bulletin
-opdx390 21381 29-Nov-1999 1621Z opdx390.1 1670 29-Nov-1999 1621Z
-opdx390.2 2193 29-Nov-1999 1621Z opdx391 25045 29-Nov-1999 1621Z
-opdx392 35969 29-Nov-1999 1621Z opdx393 15023 29-Nov-1999 1621Z
-opdx394 33429 29-Nov-1999 1621Z opdx394.1 3116 29-Nov-1999 1621Z
-opdx395 24319 29-Nov-1999 1621Z opdx396 32647 29-Nov-1999 1621Z
-opdx396.1 5537 29-Nov-1999 1621Z opdx396.2 6242 29-Nov-1999 1621Z
-opdx397 18433 29-Nov-1999 1621Z opdx398 19961 29-Nov-1999 1621Z
-opdx399 17719 29-Nov-1999 1621Z opdx400 19600 29-Nov-1999 1621Z
-opdx401 27738 29-Nov-1999 1621Z opdx402 18698 29-Nov-1999 1621Z
-opdx403 24994 29-Nov-1999 1621Z opdx404 15685 29-Nov-1999 1621Z
-opdx405 13984 29-Nov-1999 1621Z opdx405.1 4166 29-Nov-1999 1621Z
-opdx406 28934 29-Nov-1999 1621Z opdx407 24153 29-Nov-1999 1621Z
-opdx408 15081 29-Nov-1999 1621Z opdx409 23234 29-Nov-1999 1621Z
-Press Enter to continue, A to abort (16 lines) >
-</verb></tscreen>
-
-You can now read any file in this directory using the type command, like this ....
-
-<tscreen><verb>
-type bulletin/opdx391
-Ohio/Penn DX Bulletin No. 391
-The Ohio/Penn Dx PacketCluster
-DX Bulletin No. 391
-BID: $OPDX.391
-January 11, 1999
-Editor Tedd Mirgliotta, KB8NW
-Provided by BARF-80 BBS Cleveland, Ohio
-Online at 440-237-8208 28.8k-1200 Baud 8/N/1 (New Area Code!)
-Thanks to the Northern Ohio Amateur Radio Society, Northern Ohio DX
-Association, Ohio/Penn PacketCluster Network, K1XN & Golist, WB2RAJ/WB2YQH
-& The 59(9) DXReport, W3UR & The Daily DX, K3TEJ, KN4UG, W4DC, NC6J, N6HR,
-Press Enter to continue, A to abort (508 lines) >
-</verb></tscreen>
-
-The page length will of course depend on what you have it set to!
-
-<sect1>The Aliases file
-
-<P>
-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.
-
-<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.
-
-<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 = (
- 'n' => [
- '^news$', 'type news', 'type',
- ],
- '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>
-
-<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
-
-<P>
-In later versions of Spider a simple console program is provided for the sysop.
-This has a type ahead buffer with line editing facilities and colour for spots,
-announces etc. To use this program, simply use console.pl instead of client.
-
-<P>
-To edit the colours, copy /spider/perl/Console.pl to /spider/local and edit the
-file with your favourite editor.
-
-<sect1>Updating kepler data
-
-<P>
-Spider has a powerful and flexible show/satellite command. In order for
-this to be accurate, the kepler data has to be updated regularly. In
-general, this data is available as an email or via cluster mail.
-Updating it is simple. First you need to export the mail message as a
-file. You do this with the <em>export</em> command from the cluster prompt
-as the sysop. For example ...
-
-<tscreen><verb>
-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 ...
-
-<tscreen><verb>
-./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
-
-<P>
-The command <em>sh/qrz</em> will only work once you have followed a few
-simple steps. First you need to get a user ID and password from qrz.com.
-Simply go to the site and create one. Secondly you need to copy the file
-/spider/perl/Internet.pm to /spider/local and alter it to match your user
-ID and password. You also at this point need to set $allow=1 to complete
-the setup. Many thanks to Fred Lloyd, the proprieter of
-<htmlurl url="http://www.qrz.com" name="qrz.com"> for allowing this access.
-
-<sect1>Connecting logging programs
-
-<P>
-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>
-c4:2345:respawn:/sbin/agetty -L 9600 ttyS1
-</verb></tscreen>
-
-<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>
-cd /spider/spider-web
-rm *.class
-/usr/bin/javac spiderclient.java
-</verb></tscreen>
-
-<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>
-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>
-CVS stands for "Concurrent Versions System" and the CVS for DXSpider is held
-at <htmlurl url="http://www.sourceforge.net" name="Sourceforge">. This means
-that it is possible to update your DXSpider installation to the latest
-sources by using a few simple commands.
-
-<P>
-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
-Internet access running.
-
-<P>
-BEFORE YOU EVEN CONSIDER STARTING WITH THIS MAKE A BACKUP OF YOUR
-ENTIRE SPIDER TREE!!
-
-<P>
-Assuming you are connected to the Internet, you need to login to the
-CVS repository and then update your Spider source. There are several
-steps which are listed below ...
-
-<P>
-First login as the user <em>sysop</em>. Next you need to connect to the CVS
-repository. You do this with the command below ...
-
-<verb>
-cvs -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login
-</verb>
-
-You will get a password prompt. Simply hit return here and your machine should
-return to a normal linux prompt.
-
-<P>
-What happens next depends on whether you have an existing installation that
-you want to update with the latest and greatest or whether you just want
-to see what is there and/or run it on a new machine for testing.
-
-If you are installing Spider from CVS then change directory to /home/sysop
-
-If you are wanting to update Spider then cd to /tmp
-
-<P>
-The next step will create a brand new 'spider' directory in your current
-directory.
-
-<verb>
-cvs -z3 -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider co spider
-</verb>
-
-This command is all on one line.
-
-<P>
-Hopefully your screen should show you downloading files. The -z3 simply compresses
-the download to improve speed.
-When this has finished, you will have exactly the same as if you had untarred a full
-tarball PLUS some extra directories and files that CVS needs to do the magic that
-it does.
-
-<P>
-Now if you are doing a new installation, that's it. Carry on as if you have
-just downloaded and untarred the lastest tarball.
-
-<P>
-If you want to upgrade your current installation then do this ...
-
-<tscreen><verb>
-tar cvfz /tmp/s.tgz spider
-cd /
-tar xvfzp /tmp/s.tgz
-</verb></tscreen>
-
-This is assuming you downloaded to the /tmp directory of course.
-
-<P>
-NOTE: the 'p' on the end of the 'xvfz' is IMPORTANT! It keeps the permissions
-correct. YOU WERE LOGGED IN AS THE USER SYSOP WEREN'T YOU?????
-
-Remember to recompile the C client (cd /spider/src; make)
-
-<P>
-At this point the files have been upgraded. You can (usually) restart the cluster
-in your own time. However, if you attempt to use any new commands or features
-expect it to be fatal! At least your cluster will have been restarted then so it
-will be too late to worry about it!
-
-<P>
-Now the magic part! From now on when you want to update, simply connect to the
-Internet and then, as the user <em>sysop</em> ...
-
-<tscreen><verb>
-cd /spider
-cvs -z3 update -d
-</verb></tscreen>
-
-and your files will be updated. As above, remember to recompile the "C" client
-if it has been updated (CVS will tell you) and restart if any of the perl scripts
-have been altered or added, again, CVS will tell you.
-
-<P>
-You will find any changes documented in the /spider/Changes file.
-
-<sect>The DXSpider command set
-
-<P>
-Below is a complete list of commands available from the cluster prompt.
-Most maintenance tasks are automatic but there are some commands that are useful
-for a sysop. These are listed below in alphabetical order. The number in
-brackets following the command name is the permissions level needed to use
-the command.
-
-<sect1>accept/announce (0)
-
-<P>
-<tt>
-<bf>accept/announce [0-9] <pattern></bf> Set an accept filter
- line for announce
-</tt>
-
-<P>
-Create an 'accept this announce' line for a filter.
-
-An accept filter line means that if the announce matches this filter it is
-passed onto the user. See HELP FILTERS 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>
- info <string> eg: iota or qsl
- by <prefixes> eg: G,M,2
- origin <prefixes>
- origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
- origin_itu <numbers>
- origin_zone <numbers>
- by_dxcc <numbers>
- by_itu <numbers>
- by_zone <numbers>
- channel <prefixes>
- wx 1 filter WX announces
- dest <prefixes> eg: 6MUK,WDX (distros)
-</verb></tscreen>
-
-some examples:-
-
-<tscreen><verb>
- acc/ann dest 6MUK
- acc/ann 2 by_zone 14,15,16
- (this could be all on one line: acc/ann dest 6MUK or by_zone 14,15,16)
-</verb></tscreen>
-
-or
-
-<tscreen><verb>
- acc/ann by G,M,2
-</verb></tscreen>
-
-This filter would only allow announces that were posted buy UK stations.
-You can use the tag 'all' to accept everything eg:
-
-<tscreen><verb>
- acc/ann all
-</verb></tscreen>
-
-but this probably for advanced users...
-
-<sect1>accept/announce (extended for sysops) (8)
-
-<P>
-<tt>
-<bf>accept/announce <call> [input] [0-9]<pattern></bf> Announce filter sysop version
-</tt>
-
-<P>
-This version allows a sysop to set a filter for a callsign as well as the
-default for nodes and users eg:-
-
-<tscreen><verb>
- accept/ann by G,M,2
- accept/ann input node_default by G,M,2
- 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/spots [0-9] <pattern></bf> Set an accept filter
-line for spots
-</tt>
-
-<P>
-Create an 'accept this spot' line for a filter.
-
-<P>
-An accept filter line means that if the spot matches this filter it is
-passed onto the user. See HELP FILTERS 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>
- freq <range> eg: 0/30000 or hf or hf/cw or 6m,4m,2m
- on <range> same as 'freq'
- call <prefixes> eg: G,PA,HB9
- info <string> eg: iota or qsl
- by <prefixes>
- call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
- call_itu <numbers>
- call_zone <numbers>
- by_dxcc <numbers>
- by_itu <numbers>
- by_zone <numbers>
- origin <prefixes>
- channel <prefixes>
-</verb></tscreen>
-
-<P>
-For frequencies, you can use any of the band names defined in
-SHOW/BANDS and you can use a subband name like: cw, rtty, data, ssb -
-thus: hf/ssb. You can also just have a simple range like: 0/30000 -
-this is more efficient than saying simply: freq HF (but don't get
-too hung up about that)
-
-some examples:-
-
-<tscreen><verb>
- acc/spot 1 on hf/cw
- acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-</verb></tscreen>
-
-You can use the tag 'all' to accept everything, eg:
-
-<tscreen><verb>
- acc/spot 3 all
-</verb></tscreen>
-
-but this probably for advanced users...
-
-<sect1>accept/spots (extended for sysops) (8)
-
-<P>
-<tt>
-<bf>accept/spots <call> [input] [0-9] <pattern></bf> Spot filter sysop version
-</tt>
-
-<P>
-This version allows a sysop to set a filter for a callsign as well as the
-default for nodes and users eg:-
-
-<tscreen><verb>
- accept/spot db0sue-7 1 by_zone 14,15,16
- accept/spot node_default all
- set/hops node_default 10
-
- accept/spot user_default by G,M,2
-</verb></tscreen>
-
-<sect1>accept/wcy (0)
-
-<P>
-<tt>
-<bf>accept/wcy [0-9] <pattern></bf> set an accept WCY filter
-</tt>
-
-<P>
-It is unlikely that you will want to do this, but if you do then you can
-filter on the following fields:-
-
-<tscreen><verb>
- by <prefixes> eg: G,M,2
- origin <prefixes>
- origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
- origin_itu <numbers>
- origin_zone <numbers>
- by_dxcc <numbers>
- by_itu <numbers>
- by_zone <numbers>
- channel <prefixes>
-</verb></tscreen>
-
-<P>
-There are no examples because WCY Broadcasts only come from one place and
-you either want them or not (see UNSET/WCY if you don't want them).
-
-This command is really provided for future use.
-
-See HELP FILTER for information.
-
-<sect1>accept/wcy (extended for sysops) (8)
-
-<P>
-<tt>
-<bf>accept/wcy <call> [input] [0-9] <pattern></bf>
-WCY filter sysop version
-</tt>
-
-<P>
-This version allows a sysop to set a filter for a callsign as well as the
-default for nodes and users eg:-
-
-<tscreen><verb>
- accept/wcy node_default all
- set/hops node_default 10
-</verb></tscreen>
-
-<sect1>accept/wwv (0)
-
-<P>
-<tt>
-<bf>accept/wwv [0-9] <pattern></bf> Set an accept WWV filter
-</tt>
-
-<P>
-It is unlikely that you will want to do this, but if you do then you can
-filter on the following fields:-
-
-<tscreen><verb>
- by <prefixes> eg: G,M,2
- origin <prefixes>
- origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
- origin_itu <numbers>
- origin_zone <numbers>
- by_dxcc <numbers>
- by_itu <numbers>
- by_zone <numbers>
- channel <prefixes>
-</verb></tscreen>
-
-for example
-
-<tscreen><verb>
- accept/wwv by_zone 4
-</verb></tscreen>
-
-is probably the only useful thing to do (which will only show WWV broadcasts
-by stations in the US).
-
-See HELP FILTER for information.
-
-<sect1>accept/wwv (extended for sysops) (8)
-
-<P>
-<tt>
-<bf>accept/wwv <call> [input] [0-9] <pattern></bf>
-WWV filter sysop version
-</tt>
-
-<P>
-This version allows a sysop to set a filter for a callsign as well as the
-default for nodes and users eg:-
-
-<tscreen><verb>
- accept/wwv db0sue-7 1 by_zone 4
- accept/wwv node_default all
- set/hops node_default 10
-
- accept/wwv user_default by W,K
-</verb></tscreen>
-
-<sect1>announce (0)
-
-<P>
-<tt>
-<bf>announce <text></bf> Send an announcement to local users
-</tt>
-
-<P>
-Send an announcement to LOCAL users only, where <text> is the text
-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)
-
-<P>
-<tt>
-<bf>announce full <text></bf> Send an announcement cluster wide
-</tt>
-
-<P>
-This command will send your announcement across the whole cluster
-network.
-
-
-<sect1>announce sysop (5)
-
-<P>
-<tt>
-<bf>announce sysop <text></bf>
-</tt>
-
-<P>
-Send an announcement to Sysops only
-
-<sect1>apropos (0)
-
-<P>
-<tt>
-<bf>apropos <string></bf> Search the help database
-</tt>
-
-<P>
-Search the help database for <string> (it isn't case sensitive),
-and print the names of all the commands that may be relevant.
-
-<sect1>bye (0)
-
-<P>
-<tt>
-<bf>bye</bf> Exit from the cluster
-</tt>
-
-<P>
-This will disconnect you from the cluster
-
-<sect1>catchup (5)
-
-<P>
-<tt>
-<bf>catchup <node_call> All|[<msgno> ...]</bf>
-Mark a message as sent
-</tt>
-
-<P>
-When you send messages the fact that you have forwarded it to another node
-is remembered so that it isn't sent again. When you have a new partner
-node and you add their callsign to your /spider/msg/forward.pl file, all
-outstanding non-private messages will be forwarded to them. This may well
-be ALL the non-private messages. You can prevent this by using these
-commmands:-
-
-<tscreen><verb>
- catchup GB7DJK all
- catchup GB7DJK 300 301 302 303 500-510
-</verb></tscreen>
-
-and to undo what you have just done:-
-
-<tscreen><verb>
- uncatchup GB7DJK all
- uncatchup GB7DJK 300 301 302 303 500-510
-</verb></tscreen>
-
-which will arrange for them to be forward candidates again.
-
-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>
-<tt>
-<bf>clear/spots [1|all]</bf> Clear a spot filter line
-</tt>
-
-<P>
-This command allows you to clear (remove) a line in a spot filter or to
-remove the whole filter.
-
-If you have a filter:-
-
-<tscreen><verb>
- acc/spot 1 on hf/cw
- acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-</verb></tscreen>
-
-and you say:-
-
-<tscreen><verb>
- clear/spot 1
-</verb></tscreen>
-
-you will be left with:-
-
-<tscreen><verb>
- acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-</verb></tscreen>
-
-If you do:
-
-<tscreen><verb>
- clear/spot all
-</verb></tscreen>
-
-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)
-
-<P>
-<tt>
-<bf>connect <callsign></bf> Start a connection to another DX Cluster
-</tt>
-
-<P>
-Start a connection process that will culminate in a new connection to the
-DX cluster <callsign>. This process creates a new 'client' process which will
-use the script in /spider/connect/<callsign> to effect the 'chat' exchange
-necessary to traverse the network(s) to logon to the cluster <callsign>.
-
-<sect1>dbavail (0)
-
-<P>
-<tt>
-<bf>dbavail</bf> Show a list of all the databases in the system
-</tt>
-
-<P>
-The title says it all really, this command lists all the databases defined
-in the system. It is also aliased to SHOW/COMMAND.
-
-<sect1>dbcreate (9)
-
-<P>
-<tt>
-<bf>dbcreate <name></bf> Create a database entry<newline>
-<bf>dbcreate <name> chain <name> [<name>..]</bf> Create a
-chained database entry<newline>
-<bf>dbcreate <name> remote <node></bf> Create a remote database
-entry<newline>
-</tt>
-
-<P>
-DBCREATE allows you to define a database in the system. It doesn't actually
-create anything, just defines it.
-
-The databases that are created are simple DB_File hash databases, they are
-therefore already 'indexed'.
-
-You can define a local database with the first form of the command eg:
-
- DBCREATE oblast
-
-You can also chain databases with the addition of the 'chain' keyword.
-This will search each database one after the other. A typical example
-is:
-
- DBCREATE sdx_qsl chain sql_ad
-
-No checking is done to see if the any of the chained databases exist, in
-fact it is usually better to do the above statement first then do each of
-the chained databases.
-
-Databases can exist offsite. To define a database that lives on another
-node do:
-
- DBCREATE buckmaster remote gb7dxc
-
-Remote databases cannot be chained; however, the last database in a
-a chain can be a remote database eg:
-
- DBCREATE qsl chain gb7dxc
-
-To see what databases have been defined do:
-
- DBAVAIL (or it will have been aliased to SHOW/COMMAND)
-
-It would be normal for you to add an entry into your local Aliases file
-to allow people to use the 'SHOW/<dbname>' style syntax. So you would
-need to add a line like:-
-
-<tscreen><verb>
- 's' => [
- ..
- ..
- '^sh\w*/buc', 'dbshow buckmaster', 'dbshow',
- ..
- ..
- ],
-</verb></tscreen>
-
-to allow
-
- SH/BUCK g1tlh
-
-to work as they may be used to.
-
-See DBIMPORT for the importing of existing AK1A format data to databases.
-See DBSHOW for generic database enquiry
-
-<sect1>dbimport (9)
-
-<P>
-<tt>
-<bf>dbimport <dbname></bf> Import AK1A data into a database
-</tt>
-
-<P>
-If you want to import or update data in bulk to a database you can use
-this command. It will either create or update entries into an existing
-database. For example:-
-
- DBIMPORT oblast /tmp/OBLAST.FUL
-
-will import the standard OBLAST database that comes with AK1A into the
-oblast database held locally.
-
-<sect1>dbremove (9)
-
-<P>
-<tt>
-<bf>dbremove <dbname></bf> Delete a database
-</tt>
-
-<P>
-DBREMOVE will completely remove a database entry and also delete any data
-file that is associated with it.
-
-There is no warning, no comeback, no safety net.
-
-For example:
-
- DBREMOVE oblast
-
-will remove the oblast database from the system and it will also remove
-the associated datafile.
-
-I repeat:
-
-There is no warning, no comeback, no safety net.
-
-You have been warned.
-
-<sect1>dbshow (0)
-
-<P>
-<tt>
-<bf>dbshow <dbname> <key></bf> Display an entry, if it exists,
-in a database
-</tt>
-
-<P>
-This is the generic user interface to the database to the database system.
-It is expected that the sysop will add an entry to the local Aliases file
-so that users can use the more familiar AK1A style of enquiry such as:
-
-<tscreen><verb>
- SH/BUCK G1TLH
-</verb></tscreen>
-
-but if he hasn't and the database really does exist (use DBAVAIL or
-SHOW/COMMAND to find out) you can do the same thing with:
-
-<tscreen><verb>
- DBSHOW buck G1TLH
-</verb></tscreen>
-
-
-<sect1>debug (9)
-
-<P>
-<tt>
-<bf>debug</bf> Set the cluster program into debug mode
-</tt>
-
-<P>
-Executing this command will only have an effect if you are running the cluster
-in debug mode i.e.
-
-<tscreen><verb>
- perl -d cluster.pl
-</verb></tscreen>
-
-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>
-<tt>
-<bf>directory</bf> List messages<newline>
-<bf>directory all</bf> List all messages<newline>
-<bf>directory own</bf> List your own messages<newline>
-<bf>directory new</bf> List all new messages<newline>
-<bf>directory to <call></bf> List all messages to <call><newline>
-<bf>directory from <call></bf> List all messages from <call><newline>
-<bf>directory subject <string></bf> List all messages with <string>
-in subject<newline>
-<bf>directory <nn></bf> List last <nn> messages<newline>
-<bf>directory <from>-<to></bf> List messages <from> message <to> message <newline>
-</tt>
-
-<P>
-List the messages in the messages directory.
-
-If there is a 'p' one space after the message number then it is a
-personal message. If there is a '-' between the message number and the
-'p' then this indicates that the message has been read.
-
-You can use shell escape characters such as '*' and '?' in the <call>
-fields.
-
-You can combine some of the various directory commands together eg:-
-
-<tscreen><verb>
- DIR TO G1TLH 5
-or
- DIR SUBJECT IOTA 200-250
-</verb></tscreen>
-
-You can abbreviate all the commands to one letter and use ak1a syntax:-
-
-<tscreen><verb>
- DIR/T G1* 10
- DIR/S QSL 10-100 5
-</verb></tscreen>
-
-
-<sect1>directory (extended for sysops) (5)
-
-<P>
-Works just like the user command except that sysops can see ALL messages.
-
-<sect1>disconnect (8)
-
-<P>
-<tt>
-<bf>disconnect <call> [<call> ...]</bf> Disconnect a user or node
-</tt>
-
-<P>
-Disconnect any <call> connected locally
-
-<sect1>dx (0)
-
-<P>
-<tt>
-<bf>dx [by <call>] <freq> <call> <remarks></bf> Send a DX spot
-</tt>
-
-<P>
-This is how you send a DX Spot to other users. You can, in fact, now
-enter the <freq> and the <call> either way round.
-
-<tscreen><verb>
- DX FR0G 144.600
- DX 144.600 FR0G
- DX 144600 FR0G
-</verb></tscreen>
-
-will all give the same result. You can add some remarks to the end
-of the command and they will be added to the spot.
-
-<tscreen><verb>
- DX FR0G 144600 this is a test
-</verb></tscreen>
-
-You can credit someone else by saying:-
-
-<tscreen><verb>
- DX by G1TLH FR0G 144.600 he isn't on the cluster
-</verb></tscreen>
-
-The <freq> is compared against the available bands set up in the
-cluster. See SHOW/BANDS for more information.
-
-<sect1>export (9)
-
-<P>
-<tt>
-<bf>export <msgno> <filename></bf> Export a message to a file
-</tt>
-
-<P>
-Export a message to a file. This command can only be executed on a local
-console with a fully privileged user. The file produced will be in a form
-ready to be imported back into the cluster by placing it in the import
-directory (/spider/msg/import).
-
-This command cannot overwrite an existing file. This is to provide some
-measure of security. Any files written will owned by the same user as the
-main cluster, otherwise you can put the new files anywhere the cluster can
-access. For example:-
-
- EXPORT 2345 /tmp/a
-
-<sect1>export_users (9)
-
-<P>
-<tt>
-<bf>export_users [<filename>]</bf> Export the users database to ascii
-</tt>
-
-<P>
-Export the users database to a file in ascii format. If no filename
-is given then it will export the file to /spider/data/user_asc.
-
-If the file already exists it will be renamed to <filename>.o. In fact
-up to 5 generations of the file can be kept each one with an extra 'o' on the
-suffix.
-
-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>
-<tt>
-<bf>forward/latlong <node_call></bf> Send latitude and longitude
-information to another cluster
-</tt>
-
-<P>
-This command sends all the latitude and longitude information that your
-cluster is holding against callsigns. One advantage of recieving this
-information is that more locator information is held by you. This
-means that more locators are given on the DX line assuming you have
-<em>set/dxgrid</em> enabled. This could be a LOT of information though, so
-it is not recommended on slow links.
-
-<sect1>forward/opername (1)
-
-<P>
-<tt>
-<bf>forward/opername <call></bf> Send out information on this <call>
-to all clusters
-</tt>
-
-<P>
-This command sends out any information held in the user file which can
-be broadcast in PC41 protocol packets. This information is Name, QTH, Location
-and Homenode. PC41s are only sent for the information that is available.
-
-<sect1>help (0)
-
-<P>
-<tt>
-<bf>help <cmd></bf> Get help on a command
-</tt>
-
-<P>
-All commands can be abbreviated, so SHOW/DX can be abbreviated
-to SH/DX, ANNOUNCE can be shortened to AN and so on.
-
-Look at the APROPOS <string> command which will search the help database
-for the <string> you specify and give you a list of likely commands
-to look at with HELP.
-
-<sect1>init (5)
-
-<P>
-<tt>
-<bf>init <node call></bf> Re-initialise a link to an AK1A compatible node
-</tt>
-
-<P>
-This command attempts to re-initialise a link to a (usually) AK1A node
-that has got confused, usually by a protocol loop of some kind. It may
-work - but you usually will be better off simply disconnecting it (or
-better, if it is a real AK1A node, doing an RCMD <node> DISC/F <your
-node>).
-
-Best of luck - you will need it.
-
-<sect1>kill (0)
-
-<P>
-<tt>
-<bf>kill <msgno> [<msgno> ..]</bf> Delete a message
-from the local system
-</tt>
-
-<P>
-Delete a message from the local system. You will only be able to
-delete messages that you have originated or been sent (unless you are
-the sysop).
-
-<sect1>kill (5)
-
-<P>
-<tt>
-<bf>kill <msgno> [<msgno> ...]</bf> Remove or erase a message from
-the system<newline>
-<bf>kill from <call></bf> Remove all messages from a callsign<newline>
-<bf>kill to <call></bf> Remove all messages to a callsign<newline>
-</tt>
-
-<P>
-You can get rid of any message to or originating from your callsign using
-this command. You can remove more than one message at a time.
-
-As a sysop you can kill any message on the system.
-
-<sect1>kill full (5)
-
-<P>
-<tt>
-<bf>kill full <msgno> [<msgno>]</bf> Delete a message from the
-whole cluster
-</tt>
-
-<P>
-Delete a message (usually a 'bulletin') from the whole cluster system.
-
-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>
-<tt>
-<bf>links</bf> Show which nodes are physically connected
-</tt>
-
-<P>
-This is a quick listing that shows which links are connected and
-some information about them. See WHO for a list of all connections.
-
-
-<sect1>load/aliases (9)
-
-<P>
-<tt>
-<bf>load/aliases</bf> Reload the command alias table
-</tt>
-
-<P>
-Reload the /spider/cmd/Aliases file after you have editted it. You will need to
-do this if you change this file whilst the cluster is running in order for the
-changes to take effect.
-
-<sect1>load/badmsg (9)
-
-<P>
-<tt>
-<bf>load/badmsg</bf> Reload the bad message table
-</tt>
-
-<P>
-Reload the /spider/msg/badmsg.pl file if you have changed it manually whilst
-the cluster is running. This table contains a number of perl regular
-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>
-<tt>
-<bf>load/bands</bf> Reload the band limits table
-</tt>
-
-<P>
-Reload the /spider/data/bands.pl file if you have changed it manually whilst
-the cluster is running.
-
-<sect1>load/cmd_cache (9)
-
-<P>
-<tt>
-<bf>load/cmd_cache</bf> Reload the automatic command cache
-</tt>
-
-<P>
-Normally, if you change a command file in the cmd or local_cmd tree it will
-automatially be picked up by the cluster program. Sometimes it can get confused
-if you are doing a lot of moving commands about or delete a command in the
-local_cmd tree and want to use the normal one again. Execute this command to
-reset everything back to the state it was just after a cluster restart.
-
-<sect1>load/forward (9)
-
-<P>
-<tt>
-<bf>load/forward</bf> Reload the msg forwarding routing table
-</tt>
-
-Reload the /spider/msg/forward.pl file if you have changed it
-manually whilst the cluster is running.
-
-<sect1>load/messages (9)
-
-<P>
-<tt>
-<bf>load/messages</bf> Reload the system messages file
-</tt>
-
-<P>
-If you change the /spider/perl/Messages file (usually whilst fiddling/writing ne
-commands) you can have them take effect during a cluster session by executing this
-command. You need to do this if get something like :-
-
-unknown message 'xxxx' in lang 'en'
-
-<sect1>load/prefixes (9)
-
-<P>
-<tt>
-<bf>load/prefixes</bf> Reload the prefix table
-</tt>
-
-<P>
-Reload the /spider/data/prefix_data.pl file if you have changed it manually
-whilst the cluster is running.
-
-<sect1>merge (5)
-
-<P>
-<tt>
-<bf>merge <node> [<no spots>/<no wwv>]</bf> Ask for the
-latest spots and WWV
-</tt>
-
-<P>
-MERGE allows you to bring your spot and wwv database up to date. By default
-it will request the last 10 spots and 5 WWVs from the node you select. The
-node must be connected locally.
-
-You can request any number of spots or wwv and although they will be appended
-to your databases they will not duplicate any that have recently been added
-(the last 2 days for spots and last month for WWV data).
-
-<sect1>msg (9)
-
-<P>
-<tt>
-<bf>msg <cmd> <msgno> [data ...]</bf> Alter various message
-parameters
-</tt>
-
-<P>
-Alter message parameters like To, From, Subject, whether private or bulletin
-or return receipt (RR) is required or whether to keep this message from timing
-out.
-
-<tscreen><verb>
- 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 waitting 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
-</verb></tscreen>
-
-You can look at the status of a message by using:-
-
- STAT/MSG <msgno>
-
-This will display more information on the message than DIR does.
-
-<sect1>pc (8)
-
-<P>
-<tt>
-<bf>pc <call> <text></bf> Send text (eg PC Protocol) to <call>
-</tt>
-
-<P>
-Send some arbitrary text to a locally connected callsign. No processing is done on
-the text. This command allows you to send PC Protocol to unstick things if problems
-arise (messages get stuck etc). eg:-
-
- pc gb7djk PC33^GB7TLH^GB7DJK^400^
-
-You can also use in the same way as a talk command to a connected user but
-without any processing, added of "from <blah> to <blah>" or whatever.
-
- pc G1TLH Try doing that properly!!!
-
-<sect1>ping (1)
-
-<P>
-<tt>
-<bf>ping <node></bf> Check the link quality between nodes
-</tt>
-
-<P>
-his command allows you to send a frame to another cluster node on
-the network and get a return frame. The time it takes to do this
-is a good indication of the quality of the link. The actual time
-it takes is output to the console in seconds.
-Any visible cluster node can be PINGed.
-
-
-<sect1>rcmd (1)
-
-<P>
-<tt>
-<bf>rcmd <node call> <cmd></bf> Send a command to another DX cluster
-</tt>
-
-<P>
-This command allows you to send nearly any command to another DX Cluster
-node that is connected to the system.
-
-Whether you get any output is dependant on a) whether the other system knows
-that the node callsign of this cluster is in fact a node b) whether the
-other system is allowing RCMDs from this node and c) whether you have
-permission to send this command at all.
-
-<sect1>read (0)
-
-<P>
-<tt>
-<bf>read</bf> Read the next unread personal message addressed to you<newline>
-<bf>read <msgno></bf> Read the specified message<newline>
-</tt>
-
-<P>
-You can read any messages that are sent as 'non-personal' and also any
-message either sent by or sent to your callsign.
-
-
-<sect1>read (extended for sysops) (5)
-
-<P>
-<tt>
-<bf>read <msgno></bf> Read a message on the system
-</tt>
-
-<P>
-As a sysop you may read any message on the system
-
-<sect1>reject/announce
-
-<P>
-<tt>
-<bf>reject/announce [0-9] <pattern></bf> Set a reject filter
-for announce
-</tt>
-
-<P>
-Create an 'reject this announce' line for a filter.
-
-An reject filter line means that if the announce matches this filter it is
-passed onto the user. See HELP FILTERS 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>
- info <string> eg: iota or qsl
- by <prefixes> eg: G,M,2
- origin <prefixes>
- origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
- origin_itu <numbers>
- origin_zone <numbers>
- by_dxcc <numbers>
- by_itu <numbers>
- by_zone <numbers>
- channel <prefixes>
- wx 1 filter WX announces
- dest <prefixes> eg: 6MUK,WDX (distros)
-</verb></tscreen>
-
-some examples:-
-
-<tscreen><verb>
- rej/ann by_zone 14,15,16 and not by G,M,2
-</verb></tscreen>
-
-You can use the tag 'all' to reject everything eg:
-
-<tscreen><verb>
- rej/ann all
-</verb></tscreen>
-
-but this probably for advanced users...
-
-<sect1>reject/announce (extended for sysops) (8)
-
-<P>
-<tt>
-<bf>reject/announce <call> [input] [0-9] <pattern></bf> Announce filter sysop version
-</tt>
-
-<P>
-This version allows a sysop to set a filter for a callsign as well as the
-default for nodes and users eg:-
-
-<tscreen><verb>
- reject/ann by G,M,2
- reject/ann input node_default by G,M,2
- 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>
-<tt>
-<bf>reject/spots [0-9] <pattern></bf> Set a reject filter
-line for spots
-</tt>
-
-<P>
-Create a 'reject this spot' line for a filter.
-
-A reject filter line means that if the spot matches this filter it is
-dumped (not passed on). See HELP FILTERS 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>
- freq <range> eg: 0/30000 or hf or hf/cw or 6m,4m,2m
- on <range> same as 'freq'
- call <prefixes> eg: G,PA,HB9
- info <string> eg: iota or qsl
- by <prefixes>
- call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
- call_itu <numbers>
- call_zone <numbers>
- by_dxcc <numbers>
- by_itu <numbers>
- by_zone <numbers>
- origin <prefixes>
- channel <prefixes>
-</verb></tscreen>
-
-For frequencies, you can use any of the band names defined in
-SHOW/BANDS and you can use a subband name like: cw, rtty, data, ssb -
-thus: hf/ssb. You can also just have a simple range like: 0/30000 -
-this is more efficient than saying simply: on HF (but don't get
-too hung up about that)
-
-some examples:-
-
-<tscreen><verb>
- rej/spot 1 on hf
- rej/spot 2 on vhf and not (by_zone 14,15,16 or call_zone 14,15,16)
-</verb></tscreen>
-
-You can use the tag 'all' to reject everything eg:
-
-<tscreen><verb>
- rej/spot 3 all
-</verb></tscreen>
-
-but this probably for advanced users...
-
-<sect1>reject/spots (extended for sysops) (8)
-
-<P>
-<tt>
-<bf>reject/spots <call> [input] [0-9] <pattern></bf>
- Reject spot filter sysop version
-</tt>
-
-<P>
-This version allows a sysop to set a filter for a callsign as well as the
-default for nodes and users eg:-
-
-<tscreen><verb>
- reject/spot db0sue-7 1 by_zone 14,15,16
- reject/spot node_default all
- set/hops node_default 10
-
- reject/spot user_default by G,M,2
-</verb></tscreen>
-
-<sect1>reject/wcy (0)
-
-<P>
-<tt>
-<bf>reject/wcy [0-9] <pattern></bf> Set a reject WCY filter
-</tt>
-
-<P>
-It is unlikely that you will want to do this, but if you do then you can
-filter on the following fields:-
-
-<tscreen><verb>
- by <prefixes> eg: G,M,2
- origin <prefixes>
- origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
- origin_itu <numbers>
- origin_zone <numbers>
- by_dxcc <numbers>
- by_itu <numbers>
- by_zone <numbers>
- channel <prefixes>
-</verb></tscreen>
-
-There are no examples because WCY Broadcasts only come from one place and
-you either want them or not (see UNSET/WCY if you don't want them).
-
-This command is really provided for future use.
-
-See HELP FILTER for information.
-
-<sect1>reject/wcy (extended for sysops) (8)
-
-<P>
-<tt>
-<bf>reject/wcy <call> [input] [0-9] <pattern></bf>
- WCY reject filter sysop version
-</tt>
-
-<P>
-This version allows a sysop to set a filter for a callsign as well as the
-default for nodes and users eg:-
-
- reject/wcy gb7djk all
-
-<sect1>reject/wwv (0)
-
-<P>
-<tt>
-<bf>reject/wwv [0-9] <pattern></bf> Set a reject WWV filter
-</tt>
-
-<P>
-It is unlikely that you will want to do this, but if you do then you can
-filter on the following fields:-
-
-<tscreen><verb>
- by <prefixes> eg: G,M,2
- origin <prefixes>
- origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
- origin_itu <numbers>
- origin_zone <numbers>
- by_dxcc <numbers>
- by_itu <numbers>
- by_zone <numbers>
- channel <prefixes>
-</verb></tscreen>
-
-for example
-
-<tscreen><verb>
- reject/wwv by_zone 14,15,16
-</verb></tscreen>
-
-is probably the only useful thing to do (which will only show WWV broadcasts
-by stations in the US).
-
-See HELP FILTER for information.
-
-<sect1>reject/wwv (extended for sysops) (8)
-
-<P>
-<tt>
-<bf>reject/wwv <call> [input] [0-9] <pattern></bf>
- WWV reject filter sysop version
-</tt>
-
-<P>This version allows a sysop to set a filter for a callsign as well as the
-default for nodes and users eg:-
-
-<tscreen><verb>
- reject/wwv db0sue-7 1 by_zone 4
- reject/wwv node_default all
-
- reject/wwv user_default by W
-</verb></tscreen>
-
-<sect1>reply (0)
-
-<P>
-<tt>
-<bf>reply</bf> Reply (privately) to the last message that you have read<newline>
-<bf>reply <msgno></bf> Reply (privately) to the specified message<newline>
-<bf>reply B <msgno></bf> Reply as a Bulletin to the specified message<newline>
-<bf>reply NOPrivate <msgno></bf> Reply as a Bulletin to the specified
-message<newline>
-<bf>reply RR <msgno></bf> Reply to the specified message with read
-receipt<newline>
-</tt>
-
-<P>
-You can reply to a message and the subject will automatically have
-"Re:" inserted in front of it, if it isn't already present.
-
-You can also use all the extra qualifiers such as RR, PRIVATE,
-NOPRIVATE, B that you can use with the SEND command (see SEND
-for further details)
-
-<sect1>send (0)
-
-<P>
-<tt>
-<bf>send <call> [<call> ...]</bf> Send a message to
-one or more callsigns<newline>
-<bf>send RR <call></bf> Send a message and ask for a read receipt<newline>
-<bf>send COPY <msgno> <call></bf> Send a copy of a message
-to someone<newline>
-<bf>send PRIVATE <call></bf> Send a personal message<newline>
-<bf>send NOPRIVATE <call></bf> Send a message to all stations<newline>
-</tt>
-
-<P>
-All the SEND commands will create a message which will be sent either to
-an individual callsign or to one of the 'bulletin' addresses.
-
-SEND <call> on its own acts as though you had typed SEND PRIVATE, that is
-it will mark the message as personal and send it to the cluster node that
-that callsign is connected to.
-
-You can have more than one callsign in all of the SEND commands.
-
-You can have multiple qualifiers so that you can have for example:-
-
-<tscreen><verb>
- SEND RR COPY 123 PRIVATE G1TLH G0RDI
-</verb></tscreen>
-
-which should send a copy of message 123 to G1TLH and G0RDI and you will
-receive a read receipt when they have read the message.
-
-SB is an alias for SEND NOPRIVATE (or send a bulletin in BBS speak)
-SP is an alias for SEND PRIVATE
-
-<sect1>set/address (0)
-
-<P>
-<tt>
-<bf>set/address <your_address></bf> Record your postal address
-</tt>
-
-<P>
-Literally, record your address details on the cluster.
-
-<sect1>set/announce (0)
-
-<P>
-<tt>
-<bf>set/announce</bf> Allow announce messages
-</tt>
-
-<P>
-Allow announce messages to arrive at your terminal.
-
-<sect1>set/arcluster (5)
-
-<P>
-<tt>
-<bf>set/arcluster <node_call> [<node_call> ...]</bf> Make
-the node_call an AR-Cluster type node
-</tt>
-
-<P>
-Set the node_call as an AR-Cluster type node
-
-<sect1>set/baddx (8)
-
-<P>
-<tt>
-<bf>set/baddx <call></bf> Stop words we do not wish to see in the callsign field
-of a dx spot being propagated
-</tt>
-
-<P>
-Setting a word as 'baddx' will prevent spots with that word in the callsign
-field of a DX spot from going any further. They will not be displayed and they
-will not be sent onto other nodes.
-
-The word must be wriiten in full, no wild cards are allowed eg:-
-
-<tscreen><verb>
- set/baddx FORSALE VIDEO FR0G
-</verb></tscreen>
-
-To allow a word again, use the following command ...
-
-<tscreen><verb>
- unset/baddx VIDEO
-</verb></tscreen>
-
-<sect1>set/badnode (6)
-
-<P>
-<tt>
-<bf>set/badnode <node_call></bf> Stop spots from this node_call
-being propagated
-</tt>
-
-<P>
-Setting a callsign as a 'badnode' will prevent spots from that node
-going any further. They will not be displayed and they will not be
-sent onto other nodes.
-
-The call can be a full or partial call (or a prefix), eg:-
-
-<tscreen><verb>
- set/badnode K1TTT
-</verb></tscreen>
-
-will stop anything from K1TTT (including any SSID's)
-
-<tscreen><verb>
- unset/badnode K1TTT
-</verb></tscreen>
-
-will allow spots from him again.
-
-Use with extreme care. This command may well be superceded by FILTERing.
-
-<sect1>set/badspotter (8)
-
-<P>
-<tt>
-<bf>set/badspotter <call></bf> Stop spots from this callsign being propagated
-</tt>
-
-<P>
-Setting a callsign as a 'badspotter' will prevent spots from this callsign
-going any further. They will not be displayed and they will not be
-sent onto other nodes.
-
-The call must be written in full, no wild cards are allowed eg:-
-
-<tscreen><verb>
- set/badspotter VE2STN
-</verb></tscreen>
-
-will stop anything from VE2STN. If you want SSIDs as well then you must
-enter them specifically.
-
-<tscreen><verb>
- unset/badspotter VE2STN
-</verb></tscreen>
-
-will allow spots from him again.
-
-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>
-<tt>
-<bf>set/beep</bf> Add beeps to terminal messages
-</tt>
-
-<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>
-<tt>
-<bf>set/clx <node_call> [<node_call> ...]</bf> Make
-the node_call a CLX type node
-</tt>
-
-<P>
-Set the node_call as a CLX type node
-
-<sect1>set/debug (9)
-
-<P>
-<tt>
-<bf>set/debug <name></bf> Add a debug level to the debug set
-</tt>
-
-<P>
-You can choose to log several different levels. The levels are
-
-chan
-state
-msg
-cron
-connect
-
-You can show what levels you are logging with the <em>show/debug</em>
-command.
-
-You can remove a debug level with unset/debug <name>
-
-<sect1>set/dx (0)
-
-<P>
-<tt>
-<bf>set/dx</bf>Allow DX messages to arrive at your terminal
-</tt>
-
-<P>
-You can stop DX messages with the <em>unset/dx</em> command
-
-<sect1>set/dxgrid (0)
-
-<P>
-<tt>
-<bf>set/dxgrid</bf>Allow grid squares on the end of DX messages
-</tt>
-
-<P>
-Some logging programs do not like the additional information at
-the end of a DX spot. If this is the case, use the <em>unset/dxgrid</em>
-command to remove the grid squares.
-
-<sect1>set/dxnet (5)
-
-<P>
-<tt>
-<bf>set/dxnet <node_call> [<node_call> ...]</bf> Make
-the node_call a DXNet type node
-</tt>
-
-<P>
-Set the node_call as a DXNet type node
-
-<sect1>set/echo (0)
-
-<P>
-<tt>
-<bf>set/echo</bf> Make the cluster echo your input
-</tt>
-
-<P>
-If you are connected via a telnet session, different implimentations
-of telnet handle echo differently depending on whether you are
-connected via port 23 or some other port. You can use this command
-to change the setting appropriately.
-
-You can remove the echo with the <em>unset/echo</em> command
-
-The setting is stored in your user profile.
-
-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>
-<tt>
-<bf>set/here</bf> Set the here flag
-</tt>
-
-<P>
-Let others on the cluster know you are here by only displaying your
-callsign. If you are away from your terminal you can use the <em>unset/here</em>
-command to let people know you are away. This simply puts brackets
-around your callsign to indicate you are not available.
-
-<sect1>set/homenode (0)
-
-<P>
-<tt>
-<bf>set/homenode <node_call></bf> Set your home cluster
-</tt>
-
-<P>
-Tell the cluster system where you normally connect to. Any Messages sent
-to you will normally find their way there should you not be connected.
-eg:-
-
-<tscreen><verb>
- SET/HOMENODE gb7djk
-</verb></tscreen>
-
-<sect1>set/hops (8)
-
-<P>
-<tt>
-<bf>set/hops <node_call> ann|spots|wwv|wcy <n></bf>
-Set hop count
-</tt>
-
-<P>
-Set the hop count for a particular type of broadcast for a node.
-
-This command allows you to set up special hop counts for a node
-for currently: announce, spots, wwv and wcy broadcasts.
-
-<tscreen><verb>
-eg:
- set/hops gb7djk ann 10
- set/hops gb7mbc spots 20
-</verb></tscreen>
-
-Set SHOW/HOPS for information on what is already set. This command
-creates a filter and works in conjunction with the filter system.
-
-<sect1>set/isolate (9)
-
-<P>
-<tt>
-<bf>set/isolate <node call></bf> Isolate a node from the rest of the network
-</tt>
-
-<P>
-Connect a node to your system in such a way that you are a full protocol
-member of its network and can see all spots on it, but nothing either leaks
-out from it nor goes back into from the rest of the nodes connected to you.
-
-You can potentially connect several nodes in this way.
-
-You can see which nodes are isolated with the show/isolate (1) command.
-
-You can remove the isolation with the command unset/isolate.
-
-<sect1>set/language (0)
-
-<P>
-<tt>
-<bf>set/language <language></bf> Set the language you wish to use
-</tt>
-
-<P>
-You can select the language that you want the cluster to use. Currently
-the languages available are <em>en</em> (English) and <em>nl</em> (Dutch).
-
-<sect1>set/location (0)
-
-<P>
-<tt>
-<bf>set/location <lat and long></bf> Set your latitude and longitude
-</tt>
-
-<P>
-You can set your latitude and longitude manually or alternatively use the
-<em>set/qra</em> command which will do the conversion for you.
-
-<tscreen><verb>
- set/location 54 04 N 2 02 E
-</verb></tscreen>
-
-
-<sect1>set/sys_location (9)
-
-<P>
-<tt>
-<bf>set/sys_location <lat & long></bf> Set your cluster latitude and longitude
-</tt>
-
-<P>
-In order to get accurate headings and such like you must tell the system
-what your latitude and longitude is. If you have not yet done a SET/QRA
-then this command will set your QRA locator for you. For example:-
-
-<tscreen><verb>
- SET/LOCATION 52 22 N 0 57 E
-</verb></tscreen>
-
-<sect1>set/logininfo (0)
-
-<P>
-<tt>
-<bf>set/logininfo</bf> Show logins and logouts of nodes and users
-</tt>
-
-<P>
-Show users and nodes when they log in and out of the local cluster. You
-can stop these messages by using the <em>unset/logininfo</em> command.
-
-
-<sect1>set/lockout (9)
-
-<P>
-<tt>
-<bf>set/lockout <call></bf> Stop a callsign connecting to the cluster
-</tt>
-
-<P>
-You can show who is locked out with the <em>show/lockout</em> command.
-To allow the user to connect again, use the <em>unset/lockout</em> command.
-
-<sect1>set/name (0)
-
-<P>
-<tt>
-<bf>set/name <your_name></bf> Set your name
-</tt>
-
-<P>
-Tell the cluster what your name is, eg:-
-
-<tscreen><verb>
- set/name Dirk
-</verb></tscreen>
-
-<sect1>set/node (9)
-
-<P>
-<tt>
-<bf>set/node <call> [<call> ...]</bf> Make the callsign an AK1A cluster
-</tt>
-
-<P>
-Tell the system that the call(s) are to be treated as AK1A cluster and
-fed PC Protocol rather normal user commands.
-
-From version 1.41 you can also set the following types of cluster
-
-<tscreen><verb>
- set/spider
- set/dxnet
- set/clx
- set/arcluster
-</verb></tscreen>
-
-To see what your nodes are set to, use the <em>show/nodes</em> command.
-
-<sect1>set/obscount (9)
-
-<P>
-<tt>
-<bf>set/obscount <count> <node call></bf> Set the 'pump-up'
-obsolescence counter
-</tt>
-
-<P>
-From version 1.35 onwards neighbouring nodes are pinged at regular intervals (see
-SET/PINGINTERVAL), usually 300 seconds or 5 minutes. There is a 'pump-up'
-counter which is decremented on every outgoing ping and then reset to
-the 'obscount' value on every incoming ping. The default value of this
-parameter is 2.
-
-What this means is that a neighbouring node will be pinged twice at
-(default) 300 second intervals and if no reply has been heard just before
-what would be the third attempt, that node is disconnected.
-
-If a ping is heard then the obscount is reset to the full value. Using
-default values, if a node has not responded to a ping within 15 minutes,
-it is disconnected.
-
-<sect1>set/page (0)
-
-<P>
-<tt>
-<bf>set/page <n></bf> Set the number of lines per page
-</tt>
-
-<P>
-Tell the system how many lines you wish on a page when the number of lines
-of output from a command is more than this. The default is 20. Setting it
-explicitly to 0 will disable paging.
-
-<tscreen><verb>
- SET/PAGE 30
- SET/PAGE 0
-</verb></tscreen>
-
-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>
-<tt>
-<bf>set/password <callsign> <string></bf> Set a users password
-</tt>
-
-<P>
-The password for a user can only be set by a full sysop. The string
-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
-to neighbouring nodes
-</tt>
-
-<P>
-As from version 1.35 all neighbouring nodes are pinged at regular intervals
-in order to determine the rolling quality of the link and, in future, to
-affect routing decisions. The default interval is 300 secs or 5 minutes.
-
-You can use this command to set a different interval. Please don't.
-
-But if you do the value you enter is treated as minutes up 60 and seconds
-for numbers greater than that.
-
-This is used also to help determine when a link is down at the far end
-(as certain cluster software doesn't always notice), see SET/OBSCOUNT
-for more information.
-
-<sect1>set/privilege (9)
-
-<P>
-<tt>
-<bf>set/privilege <n> <call> [<call> ...]</bf> Set the
-privilege level on a call
-</tt>
-
-<P>
-Set the privilege level on a callsign. The privilege levels that pertain
-to commands are as default:-
-
-<tscreen><verb>
- 0 - normal user
- 1 - allow remote nodes normal user RCMDs
- 5 - various privileged commands (including shutdown, but not disc-
- connect), the normal level for another node.
- 8 - more privileged commands (including disconnect)
- 9 - local sysop privilege. DO NOT SET ANY REMOTE USER OR NODE TO THIS
- LEVEL.
-</verb></tscreen>
-
-If you are a sysop and you come in as a normal user on a remote connection
-your privilege will automatically be set to 0.
-
-<sect1>set/spider (5)
-
-<P>
-<tt>
-<bf>set/spider <node_call> [<node_call> ...]</bf> Make
-the node_call a DXSpider type node
-</tt>
-
-<P>
-Set the node_call as a DXSpider type node
-
-<sect1>set/sys_qra (9)
-
-<P>
-<tt>
-<bf>set/sys_qra <locator></bf> Set your cluster QRA locator
-</tt>
-
-<sect1>set/qra (0)
-
-<P>
-<tt>
-<bf>set/qra <locator></bf> Set your QRA locator
-</tt>
-
-<P>
-Tell the system what your QRA (or Maidenhead) locator is. If you have not
-done a SET/LOCATION then your latitude and longitude will be set roughly
-correctly (assuming your locator is correct ;-). For example:-
-
-<tscreen><verb>
- SET/QRA JO02LQ
-</verb></tscreen>
-
-<sect1>set/qth (0)
-
-<P>
-<tt>
-<bf>set/qth <your QTH></bf> Set your QTH
-</tt>
-
-<P>
-Tell the system where your are. For example:-
-
-<tscreen><verb>
- 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>
-<tt>
-<bf>set/talk</bf> Allow talk messages to be seen at your console
-</tt>
-
-<P>
-Allow talk messages to arrive at your console. You can switch off
-talks with the <em>unset/talk</em> command.
-
-<sect1>set/wcy (0)
-
-<P>
-<tt>
-<bf>set/wcy</bf> Allow WCY messages to be seen at your console
-</tt>
-
-<P>
-Allow WCY information to be seen at your console. You can switch off
-WCY messages with the <em>unset/wcy</em> command.
-
-<sect1>set/wwv (0)
-
-<P>
-<tt>
-<bf>set/wwv</bf> Allow WWV messages to be seen at your console
-</tt>
-
-<P>
-Allow WWV information to be seen at your console. You can switch off
-WWV messages with the <em>unset/wwv</em> command.
-
-<sect1>set/wx (0)
-
-<P>
-<tt>
-<bf>set/wx</bf> Allow WX messages to be seen at your console
-</tt>
-
-<P>
-Allow WX information to be seen at your console. You can switch off
-WX messages with the <em>unset/wx</em> command.
-
-<sect1>show/baddx (1)
-
-<P>
-<tt>
-<bf>show/baddx</bf>Show all the bad dx calls in the system
-</tt>
-
-<P>
-Display all the bad dx callsigns in the system, see SET/BADDX
-for more information.
-
-<sect1>show/badnode (6)
-
-<P>
-<tt>
-<bf>show/badnode</bf> Show all the bad nodes in the system
-</tt>
-
-<P>
-Display all the bad node callsigns in the system, see SET/BADNODE
-for more information.
-
-<sect1>show/badspotter (1)
-
-<P>
-<tt>
-<bf>show/badspotter</bf> Show all the bad spotters in the system
-</tt>
-
-<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>
-<tt>
-<bf>show/date [<prefix>|<callsign>]</bf> Show
-the local time
-</tt>
-
-<P>
-This is very nearly the same as SHOW/TIME, the only difference the format
-of the date string if no arguments are given.
-
-If no prefixes or callsigns are given then this command returns the local
-time and UTC as the computer has it right now. If you give some prefixes
-then it will show UTC and UTC + the local offset (not including DST) at
-the prefixes or callsigns that you specify.
-
-<sect1>show/debug (9)
-
-<P>
-<tt>
-<bf>show/debug</bf> Show what levels of debug you are logging
-</tt>
-
-<P>
-The levels can be set with <em>set/debug</em>
-
-<sect1>show/dx (0)
-
-<P>
-<tt>
-<bf>show/dx [options]</bf> interrogate the spot database
-</tt>
-
-<P>
-If you just type SHOW/DX you will get the last so many spots
-(sysop configurable, but usually 10).
-
-In addition you can add any number of these options in very nearly
-any order to the basic SHOW/DX command, they are:-
-
-<tscreen><verb>
-on <band> - eg 160m 20m 2m 23cm 6mm
-on <region> - eg hf vhf uhf shf (see SHOW/BANDS)
-
-<number> - the number of spots you want
-<from>-<to> - <from> spot no <to> spot no in
- the selected list
-
-<prefix> - for a spotted callsign beginning with <prefix>
-*<suffix> - for a spotted callsign ending in <suffix>
-*<string>* - for a spotted callsign containing <string>
-
-day <number> - starting <number> days ago
-day <from>-<to> - <from> days <to> days ago
-
-info <text> - any spots containing <text> in the info or remarks
-
-by <call> - any spots spotted by <call> (spotter <call>
- is the same).
-
-qsl - this automatically looks for any qsl info on the call
- held in the spot database.
-
-iota [<iota>] - If the iota island number is missing it will
- look for the string iota and anything which looks like
- an iota island number. If you specify then it will look
- for that island.
-
-qra [<locator>] - this will look for the specific locator if
- you specify one or else anything that looks like a locator.
-</verb></tscreen>
-
-e.g.
-
-<tscreen><verb>
- SH/DX 9m0
- SH/DX on 20m info iota
- SH/DX 9a on vhf day 30
- SH/DX rf1p qsl
- SH/DX iota
- SH/DX iota eu-064
- SH/DX qra jn86
-</verb></tscreen>
-
-<sect1>show/dxcc (0)
-
-<P>
-<tt>
-<bf>show/dxcc <prefix></bf> Interrogate the spot database by country
-</tt>
-
-<P>
-This command takes the <prefix> (which can be a full or partial
-callsign if desired), looks up which internal country number it is
-and then displays all the spots as per SH/DX for that country.
-
-The options for SHOW/DX also apply to this command.
-e.g.
-
-<tscreen><verb>
- SH/DXCC G
- 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>
-<tt>
-<bf>show/files [<filearea> [<string>]]</bf> List
-the contents of a filearea
-</tt>
-
-<P>
-SHOW/FILES on its own will show you a list of the various fileareas
-available on the system. To see the contents of a particular file
-area type:-
-
-<tscreen><verb>
- SH/FILES <filearea>
-</verb></tscreen>
-
-where <filearea> is the name of the filearea you want to see the
-contents of.
-
-You can also use shell globbing characters like '*' and '?' in a
-string to see a selection of files in a filearea eg:-
-
-<tscreen><verb>
- SH/FILES bulletins arld*
-</verb></tscreen>
-
-See also TYPE - to see the contents of a file.
-
-<sect1>show/filter (0)
-
-<P>
-<tt>
-<bf>show/filter</bf> Show the filters you have set
-</tt>
-
-<P>
-Show the contents of all the filters that are set by you. This command
-displays all the filters set - for all the various categories.
-
-<sect1>show/filter (extended for sysops) (5)
-
-<P>
-<tt>
-<bf>show/filter <callsign></bf> Show the filters set by <callsign>
-</tt>
-
-<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>
-<tt>
-<bf>show/hops <node_call> [ann|spots|wcy|wwv|]</bf> Show the hop
-counts for a node
-</tt>
-
-<P>
-This command shows the hop counts set up for a node. You can specify
-which category you want to see. If you leave the category out then
-all the categories will be listed.
-
-<sect1>show/isolate (1)
-
-<P>
-<tt>
-<bf>show/isolate</bf> Show a list of isolated nodes
-</tt>
-
-<P>
-Show which nodes are currently set to be isolated.
-
-<sect1>show/lockout (9)
-
-<P>
-<tt>
-<bf>show/lockout</bf> Show a list of excluded callsigns
-</tt>
-
-<P>
-Show a list of callsigns that have been excluded (locked out) of the
-cluster locally with the <em>set/lockout</em> command
-
-<sect1>show/log (8)
-
-<P>
-<tt>
-<bf>show/log [<callsign>]</bf> Show excerpts from the system log
-</tt>
-
-<P>
-This command outputs a short section of the system log. On its own
-it will output a general logfile. With the optional callsign it will
-show output from the log associated with that callsign.
-
-<sect1>show/moon (0)
-
-<P>
-<tt>
-<bf>show/moon [<prefix>|<callsign>]</bf> Show moon
-rise and set times
-</tt>
-
-<P>
-Show the Moon rise and set times for a (list of) prefixes or callsigns,
-together with the azimuth and elevation of the sun currently at those
-locations.
-
-If you don't specify any prefixes or callsigns, it will show the times for
-your QTH (assuming you have set it with either SET/LOCATION or SET/QRA),
-together with the current azimuth and elevation.
-
-In addition, it will show the gain or loss dB relative to the nominal
-distance of 385,000Km due to the ellipsoidal nature of the orbit.
-
-If all else fails it will show the Moonrise and set times for the node
-that you are connected to.
-
-For example:-
-
-<tscreen><verb>
- SH/MOON
- SH/MOON G1TLH W5UN
-</verb></tscreen>
-
-<sect1>show/muf (0)
-
-<P>
-<tt>
-<bf>show/muf <prefix> [<hours>][long]</bf> Show
-the likely propagation to <prefix>
-</tt>
-
-<P>
-This command allow you to estimate the likelihood of you contacting
-a station with the prefix you have specified. The output assumes a modest
-power of 20dBW and receiver sensitivity of -123dBm (about 0.15muV/10dB SINAD)
-
-The result predicts the most likely operating frequencies and signal
-levels for high frequency (shortwave) radio propagation paths on
-specified days of the year and hours of the day. It is most useful for
-paths between 250 km and 6000 km, but can be used with reduced accuracy
-for paths shorter or longer than this.
-
-The command uses a routine MINIMUF 3.5 developed by the U.S. Navy and
-used to predict the MUF given the predicted flux, day of the year,
-hour of the day and geographic coordinates of the transmitter and
-receiver. This routine is reasonably accurate for the purposes here,
-with a claimed RMS error of 3.8 MHz, but much smaller and less complex
-than the programs used by major shortwave broadcasting organizations,
-such as the Voice of America.
-
-The command will display some header information detailing its
-assumptions, together with the locations, latitude and longitudes and
-bearings. It will then show UTC (UT), local time at the other end
-(LT), calculate the MUFs, Sun zenith angle at the midpoint of the path
-(Zen) and the likely signal strengths. Then for each frequency for which
-the system thinks there is a likelihood of a circuit it prints a value.
-
-The value is currently a likely S meter reading based on the conventional
-6dB / S point scale. If the value has a '+' appended it means that it is
-1/2 an S point stronger. If the value is preceeded by an 'm' it means that
-there is likely to be much fading and by an 's' that the signal is likely
-to be noisy.
-
-By default SHOW/MUF will show the next two hours worth of data. You
-can specify anything up to 24 hours worth of data by appending the no of
-hours required after the prefix. For example:-
-
-<tscreen><verb>
- SH/MUF W
-</verb></tscreen>
-
-produces:
-
-<tscreen><verb>
- RxSens: -123 dBM SFI: 159 R: 193 Month: 10 Day: 21
- Power : 20 dBW Distance: 6283 km Delay: 22.4 ms
- Location Lat / Long Azim
- East Dereham, Norfolk 52 41 N 0 57 E 47
- United-States-W 43 0 N 87 54 W 299
- UT LT MUF Zen 1.8 3.5 7.0 10.1 14.0 18.1 21.0 24.9 28.0 50.0
- 18 23 11.5 -35 mS0+ mS2 S3
- 19 0 11.2 -41 mS0+ mS2 S3
-</verb></tscreen>
-
-indicating that you will have weak, fading circuits on top band and
-80m but usable signals on 40m (about S3).
-
-inputting:-
-
-<tscreen><verb>
- SH/MUF W 24
-</verb></tscreen>
-
-will get you the above display, but with the next 24 hours worth of
-propagation data.
-
-<tscreen><verb>
- SH/MUF W L 24
- SH/MUF W 24 Long
-</verb></tscreen>
-
-Gives you an estimate of the long path propagation characterics. It
-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>
-<tt>
-<bf>show/node [<node_call> ...]</bf> Show the type and version
-number of nodes
-</tt>
-
-<P>
-Show the type and version (if connected) of the nodes specified on the
-command line. If no callsigns are specified then a sorted list of all
-the non-user callsigns known to the system will be displayed.
-
-<sect1>show/prefix (0)
-
-<P>
-<tt>
-<bf>show/prefix <callsign></bf> Interrogate the prefix database
-</tt>
-
-<P>
-This command takes the <callsign> (which can be a full or partial
-callsign or a prefix), looks up which internal country number
-it is and then displays all the relevant prefixes for that country
-together with the internal country no, the CQ and ITU regions.
-
-See also SHOW/DXCC
-
-
-<sect1>show/program (5)
-
-<P>
-<tt>
-<bf>show/program</bf> Show the locations of all the included program modules
-</tt>
-
-<P>
-Show the name and location where every program module was load from. This
-is useful for checking where you think you have loaded a .pm file from.
-
-<sect1>show/qra (0)
-
-<P>
-<tt>
-<bf>show/qra <locator> [<locator>]</bf> Show the distance
-between locators<newline>
-<bf>show/qra <lat> <long></bf> Convert latitude and longitude to
-a locator
-</tt>
-
-<P>
-This is a multipurpose command that allows you either to calculate the
-distance and bearing between two locators or (if only one locator is
-given on the command line) the distance and beraing from your station
-to the locator. For example:-
-
-<tscreen><verb>
-SH/QRA IO92QL
-SH/QRA JN06 IN73
-</verb></tscreen>
-
-The first example will show the distance and bearing to the locator from
-yourself, the second example will calculate the distance and bearing from
-the first locator to the second. You can use 4 or 6 character locators.
-
-It is also possible to convert a latitude and longitude to a locator by
-using this command with a latitude and longitude as an argument, for
-example:-
-
-<tscreen><verb>
-SH/QRA 52 41 N 0 58 E
-</verb></tscreen>
-
-<sect1>show/qrz (0)
-
-<P>
-<tt>
-<bf>show/qrz <callsign></bf> Show any callbook details on a callsign
-</tt>
-
-<P>
-This command queries the QRZ callbook server on the internet
-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>
-<tt>
-<bf>show/route <callsign></bf> Show the route to <callsign>
-</tt>
-
-<P>
-This command allows you to see to which node the callsigns specified are
-connected. It is a sort of inverse sh/config.
-
-<tscreen><verb>
- sh/route n2tly
-</verb></tscreen>
-
-<sect1>show/satellite (0)
-
-<P>
-<tt>
-<bf>show/satellite <name> [<hours> <interval>]</bf>
-Show satellite tracking data
-</tt>
-
-<P>
-Show the tracking data from your location to the satellite of your choice
-from now on for the next few hours.
-
-If you use this command without a satellite name it will display a list
-of all the satellites known currently to the system.
-
-If you give a name then you can obtain tracking data of all the passes
-that start and finish 5 degrees below the horizon. As default it will
-give information for the next three hours for every five minute period.
-
-You can alter the number of hours and the step size, within certain
-limits.
-
-Each pass in a period is separated with a row of '-----' characters
-
-So for example:-
-
-<tscreen><verb>
-SH/SAT AO-10
-SH/SAT FENGYUN1 12 2
-</verb></tscreen>
-
-<sect1>show/sun (0)
-
-<P>
-<tt>
-<bf>show/sun [<prefix>|<callsign>]</bf> Show
-sun rise and set times
-</tt>
-
-<P>
-Show the sun rise and set times for a (list of) prefixes or callsigns,
-together with the azimuth and elevation of the sun currently at those
-locations.
-
-If you don't specify any prefixes or callsigns, it will show the times for
-your QTH (assuming you have set it with either SET/LOCATION or SET/QRA),
-together with the current azimuth and elevation.
-
-If all else fails it will show the sunrise and set times for the node
-that you are connected to.
-
-For example:-
-
-<tscreen><verb>
- SH/SUN
- SH/SUN G1TLH K9CW ZS
-</verb></tscreen>
-
-<sect1>show/time (0)
-
-<P>
-<tt>
-<bf>show/time [<prefix>|<callsign>]</bf> Show
-the local time
-</tt>
-
-<P>
-If no prefixes or callsigns are given then this command returns the local
-time and UTC as the computer has it right now. If you give some prefixes
-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>
-<tt>
-<bf>show/wcy</bf> Show the last 10 WCY broadcasts<newline>
-<bf>show/wcy <n></bf> Show the last <n> WCY broadcasts
-</tt>
-
-<P>
-Display the most recent WCY information that has been received by the system
-
-<sect1>show/wwv (0)
-
-<P>
-<tt>
-<bf>show/wwv</bf> Show the last 10 WWV broadcasts<newline>
-<bf>show/wwv <n></bf> Show the last <n> WWV broadcasts
-</tt>
-
-<P>
-Display the most recent WWV information that has been received by the system
-
-
-<sect1>shutdown (5)
-
-<P>
-<tt>
-<bf>shutdown</bf> Shutdown the cluster
-</tt>
-
-<P>
-Shutdown the cluster and disconnect all the users. If you have Spider
-set to respawn in /etc/inittab it will of course restart.
-
-<sect1>spoof (9)
-
-<P>
-<tt>
-<bf>spoof <callsign> <command></bf> Run commands as another user
-</tt>
-
-<P>
-This is a very simple yet powerful command for the sysop. It allows you to
-issue commands as if you were a different user. This is very useful for the
-kind of things that users seem to always get wrong.. like home_node for
-example.
-
-<sect1>stat/db (5)
-
-<P>
-<tt>
-<bf>stat/db <dbname></bf> Show the status of a database
-</tt>
-
-<P>
-Show the internal status of a database descriptor.
-
-Depending on your privilege level you will see more or less information.
-This command is unlikely to be of much use to anyone other than a sysop.
-
-<sect1>stat/channel (5)
-
-<P>
-<tt>
-<bf>stat/channel <callsign></bf> Show the status of a channel on the cluster
-</tt>
-
-<P>
-Show the internal status of the channel object either for the channel that
-you are on or else for the callsign that you asked for.
-
-Only the fields that are defined (in perl term) will be displayed.
-
-<sect1>stat/msg (5)
-
-<P>
-<tt>
-<bf>stat/msg <msgno></bf> Show the status of a message
-</tt>
-
-<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>
-<tt>
-<bf>stat/user <callsign></bf> Show the full status of a user
-</tt>
-
-<P>
-Shows the full contents of a user record including all the secret flags
-and stuff.
-
-Only the fields that are defined (in perl term) will be displayed.
-
-<sect1>sysop (0)
-
-<P>
-<tt>
-<bf>sysop</bf> Regain your privileges if you login remotely
-</tt>
-
-<P>
-The system automatically reduces your privilege level to that of a
-normal user if you login in remotely. This command allows you to
-regain your normal privilege level. It uses the normal system: five
-numbers are returned that are indexes into the character array that is
-your assigned password (see SET/PASSWORD). The indexes start from
-zero.
-
-You are expected to return a string which contains the characters
-required in the correct order. You may intersperse those characters
-with others to obscure your reply for any watchers. For example (and
-these values are for explanation :-):
-
-<tscreen><verb>
- password = 012345678901234567890123456789
- > sysop
- 22 10 15 17 3
-</verb></tscreen>
-
-you type:-
-
-<tscreen><verb>
- aa2bbbb0ccc5ddd7xxx3n
- or 2 0 5 7 3
- or 20573
-</verb></tscreen>
-
-They will all match. If there is no password you will still be offered
-numbers but nothing will happen when you input a string. Any match is
-case sensitive.
-
-<sect1>talk (0)
-
-<P>
-<tt>
-<bf>talk <callsign></bf> Enter talk mode with <callsign><newline>
-<bf>talk <callsign> <text></bf> Send a text message to <callsign><newline>
-<bf>talk <callsign> > <node_call> [<text>]</bf>
-Send a text message to <callsign> via <node_call>
-</tt>
-
-<P>
-Send a short message to any other station that is visible on the cluster
-system. You can send it to anyone you can see with a SHOW/CONFIGURATION
-command, they don't have to be connected locally.
-
-The second form of TALK is used when other cluster nodes are connected
-with restricted information. This usually means that they don't send
-the user information usually associated with logging on and off the cluster.
-
-If you know that G3JNB is likely to be present on GB7TLH, but you can only
-see GB7TLH in the SH/C list but with no users, then you would use the
-second form of the talk message.
-
-If you want to have a ragchew with someone you can leave the text message
-out and the system will go into 'Talk' mode. What this means is that a
-short message is sent to the recipient telling them that you are in a 'Talking'
-frame of mind and then you just type - everything you send will go to the
-station that you asked for.
-
-All the usual announcements, spots and so on will still come out on your
-terminal.
-
-If you want to do something (such as send a spot) you precede the normal
-command with a '/' character, eg:-
-
-<tscreen><verb>
- /DX 14001 G1TLH What's a B class licensee doing on 20m CW?
- /HELP talk
-</verb></tscreen>
-
-To leave talk mode type:
-
-<tscreen><verb>
- /EX
-</verb></tscreen>
-
-<sect1>type (0)
-
-<P>
-<tt>
-<bf>type <filearea>/<name></bf> Look at a file in one of the fileareas
-</tt>
-
-<P>
-Type out the contents of a file in a filearea. So, for example, in
-filearea 'bulletins' you want to look at file 'arld051' you would
-enter:-
-
-<tscreen><verb>
- TYPE bulletins/arld051
-</verb></tscreen>
-
-See also SHOW/FILES to see what fileareas are available and a
-list of content.
-
-<sect1>who (0)
-
-<P>
-<tt>
-<bf>who</bf> Show who is physically connected locally
-</tt>
-
-<P>
-This is a quick listing that shows which callsigns are connected and
-what sort of connection they have
-
-<sect1>wx (0)
-
-<P>
-<tt>
-<bf>wx <text></bf> Send a weather message to local users<newline>
-<bf>wx full <text> </bf> Send a weather message to all cluster users
-</tt>
-
-<P>
-Weather messages can sometimes be useful if you are experiencing an extreme
-that may indicate enhanced conditions
-
-<sect1>wx (enhanced for sysops) (5)
-
-<P>
-<tt>
-<bf>wx sysop <text></bf> Send a weather message to other clusters only
-</tt>
-
-<P>
-Send a weather message only to other cluster nodes and not to general users.
-
-
-
-</article>
+<!doctype linuxdoc system>\r
+\r
+<article>\r
+\r
+<!-- Title information -->\r
+\r
+<title>The DXSpider Administration Manual v1.50</title> \r
+<author>Ian Maude, G0VGS, (g0vgs@gb7mbc.net), and\r
+Charlie Carroll, K1XX, (k1xx@ptcnh.net)</author>\r
+<date>July 2002 revision 0.1</date>\r
+\r
+<abstract>\r
+A reference for SysOps of the DXSpider DXCluster program.\r
+</abstract>\r
+\r
+<!-- Table of contents -->\r
+<toc>\r
+\r
+<!-- Begin the document -->\r
+\r
+<sect>Routing and Filtering\r
+\r
+<sect1>Introduction\r
+\r
+<P>\r
+From DXSpider version 1.48, major changes were introduced to the way \r
+node connections are treated. This is part of an ongoing process to\r
+remove problems with loops and to enable talk and other functions to\r
+propagate across the whole of the worldwide cluster network. In fact,\r
+in a Spider network, it would be useful, perhaps even necessary to\r
+have loops. This would give real resilience to the network, meaning\r
+that if a link dropped, the information flow would simply come in and\r
+go out via a different route. Of course, we do not have a complete\r
+network of Spider nodes, there are other programs out there. Some of\r
+these do not have any protection from loops. Certainly AK1A does not \r
+handle loops well at all. It is therefore necessary to have some form \r
+of protection for these nodes.\r
+\r
+<P>\r
+In fact DXSpider has had a simple system for some time which is called\r
+<it>isolation</it>. This is similar to what in other systems such as \r
+<bf>clx</bf>, is called <it>passive mode</it>. A more detailed explanation\r
+of <it>isolation</it> is given further below. This system is still available\r
+and, for simple networks, is probably all that you need.\r
+\r
+<P>\r
+The new functionality introduced in version 1.48 allows filtering the node\r
+and user protocol frames on a "per interface" basis. We call this\r
+<it>route filtering</it>. This is used <bf>instead of</bf>\r
+<it>isolation</it>. \r
+\r
+<p>\r
+What this really means is that you can control more or less completely\r
+which user and node management PC protocol frames pass to each of your \r
+partner nodes. You can also limit what comes into your node from your \r
+partners. It is even possible to control the settings that your partner \r
+node has for the routing information that it sends to you \r
+(using the <it>rcmd</it> command).\r
+\r
+<sect1>Route Filters\r
+\r
+<p>\r
+Initially when route filters were being tested we generated a\r
+"default" filter. Unfortunately it quickly became apparent that this\r
+might suit the UK cluster network but didn't really fit anybody else.\r
+However using a default filter is an appropriate thing to do. How, is\r
+explained further on.\r
+\r
+<p>\r
+The first thing that you must do is determine whether you need to use \r
+route filtering <bf>at all</bf>. If you are a "normal" node with two or \r
+three partners and you arranged in an "official" non-looping tree type \r
+network, then <bf>you do not need to do route filtering</bf> and you will \r
+feel a lot better for not getting involved. If you are successfully using \r
+<it>isolation</it> then you also probably don't need to use route filtering.\r
+\r
+<p>\r
+To put it simply, you should not mix Isolation and Route Filtering. It \r
+will work, of sorts, but you will not get the expected results. If you \r
+are using Isolation sucessfully at the moment, do not get involved in \r
+Route Filtering unless you have a good supply of aspirin! Once you have \r
+started down the road of Route Filtering, do not use Isolation either.\r
+Use one or the other, not both.\r
+\r
+<p>\r
+You will only require this functionality if you are "well-connected". What \r
+that means is that you are connected to several different parts of (say) \r
+the EU cluster and, at the same time, also connected to two or three places \r
+in the US which, in turn are connected back to the EU. This is called a \r
+"loop" and if you are seriously looped then you need filtering.\r
+\r
+<P>\r
+I should at this stage give a little bit of background on filters. All\r
+the filters in Spider work in basically the same way. You can either\r
+accept or reject various options in order to create the filter rules\r
+you wish to achieve. Some filters are user settable, others can only\r
+be altered by the sysop. Route filtering can only be done by the sysop.\r
+\r
+<P> \r
+Anyway, without further discouragement, let me start the process\r
+of explanation.\r
+\r
+<sect1>The node_default filter\r
+\r
+<P>\r
+All normal systems should have a default routing filter and it should\r
+usually be set to send only the normal, unlooped, view of your\r
+"national" network. Here in the UK that means nodes from the UK and\r
+Eire, in EU it is more complex as the networks there grew up in a more\r
+intertwined way.\r
+\r
+<p> \r
+The generic commands are:-\r
+\r
+<tscreen><verb>\r
+reject/route node_default <filter_option>\r
+\r
+or\r
+\r
+accept/route node_default <filter_option>\r
+</verb></tscreen>\r
+\r
+where filter_option is one of the following ...\r
+\r
+<tscreen><verb>\r
+call <prefixes>\r
+call_dxcc <numbers>\r
+call_itu <numbers>\r
+call_zone <numbers>\r
+channel <prefixes>\r
+channel_dxcc <numbers>\r
+channel_itu <numbers>\r
+channel_zone <numbers>\r
+</verb></tscreen>\r
+\r
+Please be careful if you alter this setting, it will affect \r
+<bf><it>ALL</it></bf> your links! Remember, this is a <it>default</it>\r
+filter for node connections, not a <it>per link</it> default.\r
+\r
+<p>\r
+For the default routing filter then you have two real choices: either\r
+a "national" view or the "safe" option of only your own\r
+callsign. Examples of each (for my node: GB7DJK) are:-\r
+\r
+<tscreen><verb>\r
+acc/route node_default call_dxcc 61,38\r
+acc/route node_default call gb7djk\r
+</verb></tscreen>\r
+\r
+GB7DJK uses the first of these. The DXCC countries can be obtained from the \r
+<it>show/prefix</it> command.\r
+\r
+<p>\r
+The example filters shown control <it>output</it> <bf>TO</bf> all your\r
+partner nodes unless they have a specific filter applied to them (see\r
+next section).\r
+\r
+<p>\r
+It is also possible to control the <it>incoming</it> routing\r
+information that you are prepared to accept <bf>FROM</bf> your partner\r
+nodes. The reason this is necessary is to make sure that stuff like\r
+mail, pings and similar commands a) go down the correct links and b)\r
+don't loop around excessively. Again using GB7DJK as an example a typical\r
+default input filter would be something like:\r
+\r
+<tscreen><verb>\r
+rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38\r
+</verb></tscreen>\r
+\r
+What this does is accept node and user information for our national\r
+network from nodes that are in our national network, but rejects such\r
+information from anyone else. Although it doesn't explicitly say so,\r
+by implication, any other node information (not from the UK and Eire)\r
+is accepted.\r
+\r
+<p>\r
+As I imagine it will take a little while to get one's head around all of \r
+this you can study the effect of any rules that you try by watching the \r
+debug output after having done:-\r
+\r
+<tscreen><verb>\r
+set/debug filter\r
+</verb></tscreen>\r
+\r
+After you have got tired of that, to put it back the way it was:-\r
+\r
+<tscreen><verb>\r
+unset/debug filter\r
+</verb></tscreen>\r
+\r
+<sect1>General route filtering\r
+\r
+<P>\r
+Exactly the same rules apply for general route filtering. You would\r
+use either an accept filter or a reject filter like this ...\r
+\r
+<tscreen><verb>\r
+reject/route <node_call> <filter_option>\r
+\r
+or\r
+\r
+accept/route <node_call> <filter_option> \r
+</verb></tscreen>\r
+\r
+<P>\r
+Here are some examples of route filters ...\r
+\r
+<tscreen><verb>\r
+rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes)\r
+rej/route all (equiv to [very] restricted mode)\r
+acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)\r
+acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)\r
+</verb></tscreen>\r
+\r
+In practice you will either be opening the default filter out for a\r
+partner by defining a specific filter for that callsign:-\r
+ \r
+<tscreen><verb>\r
+acc/route gb7baa all\r
+acc/route gb7baa input all\r
+</verb></tscreen>\r
+\r
+or restricting it quite a lot, in fact making it very nearly like an \r
+<it>isolated</it> node, like this:-\r
+\r
+<tscreen><verb>\r
+acc/route pi4ehv-8 call gb7djk\r
+rej/route pi4ehv-8 input call_dxcc 61,38 \r
+</verb></tscreen>\r
+\r
+This last example takes everything except UK and Eire from PI4EHV-8\r
+but only sends him my local configuration (just a PC19 for GB7DJK and\r
+PC16s for my local users).\r
+\r
+<p>\r
+It is possible to write <bf>much</bf> more complex rules, there are up \r
+to 10 accept/reject pairs per callsign per filter. For more information \r
+see the next section. \r
+\r
+\r
+<sect1>General filter rules\r
+\r
+<P>\r
+Upto v1.44 it was not possible for the user to set their own filters. From \r
+v1.45 though that has all changed. It is now possible to set filters for just \r
+about anything you wish. If you have just updated from an older version of \r
+DXSpider you will need to update your new filters. You do not need to do \r
+anything with your old filters, they will be renamed as you update.\r
+\r
+<P>\r
+There are 3 basic commands involved in setting and manipulating filters. These \r
+are <em>accept</em>, <em>reject</em> and <em>clear</em>. First we will look\r
+generally at filtering. There are a number of things you can filter in the \r
+DXSpider system. They all use the same general mechanism.\r
+\r
+<P>\r
+In general terms you can create a "reject" or an "accept" filter which can have \r
+up to 10 lines in it. You do this using, for example ... \r
+\r
+<tscreen><verb> \r
+accept/spots .....\r
+reject/spots .....\r
+</verb></tscreen>\r
+\r
+where ..... are the specific commands for that type of filter. There are filters \r
+for spots, wwv, announce, wcy and (for sysops) connects. See each different \r
+accept or reject command reference for more details.\r
+\r
+There is also a command to clear out one or more lines in a filter. They are ...\r
+\r
+<tscreen><verb>\r
+clear/spots 1\r
+clear/spots all\r
+</verb></tscreen>\r
+\r
+There is clear/xxxx command for each type of filter.\r
+\r
+<P>\r
+and you can check that your filters have worked by the command ... \r
+\r
+<tscreen><verb> \r
+show/filter\r
+</verb></tscreen>\r
+\r
+<P>\r
+For now we are going to use spots for the examples, but you can apply the same\r
+principles to all types of filter.\r
+\r
+<sect1>Types of filter\r
+\r
+<P>\r
+There are two main types of filter, <em>accept</em> or <em>reject</em>. You \r
+can use either to achieve the result you want dependent on your own preference \r
+and which is more simple to do. It is pointless writing 8 lines of reject \r
+filters when 1 accept filter would do the same thing! Each filter has 10 \r
+lines (of any length) which are tried in order. If a line matches then the \r
+action you have specified is taken (ie reject means ignore it and accept \r
+means take it)\r
+\r
+<P>\r
+If you specify reject filters, then any lines that arrive that match the filter \r
+will be dumped but all else will be accepted. If you use an accept filter, \r
+then ONLY the lines in the filter will be accepted and all else will be dumped.\r
+For example if you have a single line <em>accept</em> filter ...\r
+\r
+<tscreen><verb>\r
+accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)\r
+</verb></tscreen>\r
+\r
+then you will <em>ONLY</em> get VHF spots <em>from</em> or <em>to</em> CQ zones \r
+14, 15 and 16.\r
+\r
+<P>\r
+If you set a reject filter like this ...\r
+\r
+<tscreen><verb>\r
+reject/spots on hf/cw\r
+</verb></tscreen>\r
+\r
+Then you will get everything <em>EXCEPT</em> HF CW spots. You could make this \r
+single filter even more flexible. For example, if you are interested in IOTA \r
+and will work it even on CW even though normally you are not interested in \r
+CW, then you could say ...\r
+\r
+<tscreen><verb>\r
+reject/spots on hf/cw and not info iota\r
+</verb></tscreen>\r
+\r
+But in that case you might only be interested in iota and say:-\r
+\r
+<tscreen><verb>\r
+accept/spots not on hf/cw or info iota\r
+</verb></tscreen>\r
+\r
+which achieves exactly the same thing. You should choose one or the other \r
+until you are comfortable with the way it works. You can mix them if you \r
+wish (actually you can have an accept AND a reject on the same line) but \r
+don't attempt this until you are sure you know what you are doing!\r
+\r
+<P>\r
+You can arrange your filter lines into logical units, either for your own\r
+understanding or simply convenience. Here is an example ...\r
+\r
+<tscreen><verb>\r
+reject/spots 1 on hf/cw\r
+reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16) \r
+</verb></tscreen>\r
+\r
+What this does is to ignore all HF CW spots and also rejects any spots on VHF \r
+which don't either originate or spot someone in Europe. \r
+\r
+<P>\r
+This is an example where you would use a line number (1 and 2 in this case), if \r
+you leave the digit out, the system assumes '1'. Digits '0'-'9' are available. \r
+This make it easier to see just what filters you have set. It also makes it \r
+more simple to remove individual filters, during a contest for example.\r
+\r
+<P>\r
+You will notice in the above example that the second line has brackets. Look \r
+at the line logically. You can see there are 2 separate sections to it. We \r
+are saying reject spots that are VHF or above <em>APART</em> from those in \r
+zones 14, 15 and 16 (either spotted there or originated there). If you did \r
+not have the brackets to separate the 2 sections, then Spider would read it \r
+logically from the front and see a different expression entirely ...\r
+\r
+<tscreen><verb>\r
+(on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16 \r
+</verb></tscreen>\r
+\r
+The simple way to remember this is, if you use OR - use brackets. Whilst we are \r
+here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'.\r
+\r
+As mentioned earlier, setting several filters can be more flexible than \r
+simply setting one complex one. Doing it in this way means that if you want \r
+to alter your filter you can just redefine or remove one or more lines of it or \r
+one line. For example ...\r
+\r
+<tscreen><verb>\r
+reject/spots 1 on hf/ssb\r
+</verb></tscreen>\r
+\r
+would redefine our earlier example, or \r
+\r
+<tscreen><verb>\r
+clear/spots 1\r
+</verb></tscreen>\r
+\r
+To remove all the filter lines in the spot filter ...\r
+\r
+<tscreen><verb>\r
+clear/spots all\r
+</verb></tscreen>\r
+\r
+<sect1>Filter options\r
+\r
+<P>\r
+You can filter in several different ways. The options are listed in the\r
+various helpfiles for accept, reject and filter.\r
+\r
+<sect1>Default filters\r
+\r
+<P>\r
+Sometimes all that is needed is a general rule for node connects. This can\r
+be done with a node_default filter. This rule will always be followed, even\r
+if the link is isolated, unless another filter is set specifically. Default\r
+rules can be set for nodes and users. They can be set for spots, announces,\r
+WWV and WCY. They can also be used for hops. An example might look like \r
+this ...\r
+\r
+<tscreen><verb>\r
+accept/spot node_default by_zone 14,15,16,20,33\r
+set/hops node_default spot 50\r
+</verb></tscreen>\r
+\r
+This filter is for spots only, you could set others for announce, WWV and WCY.\r
+This filter would work for ALL nodes unless a specific filter is written to \r
+override it for a particular node. You can also set a user_default should\r
+you require. It is important to note that default filters should be\r
+considered to be "connected". By this I mean that should you override the\r
+default filter for spots, you need to add a rule for the hops for spots also.\r
+\r
+<sect1>Advanced filtering\r
+\r
+<P>\r
+Once you are happy with the results you get, you may like to experiment. \r
+\r
+<P>\r
+The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU \r
+can be written with a mixed filter, for example ... \r
+\r
+<tscreen><verb>\r
+rej/spot on hf/cw\r
+acc/spot on 0/30000\r
+acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)\r
+</verb></tscreen>\r
+\r
+Note that the first filter has not been specified with a number. This will \r
+automatically be assumed to be number 1. In this case, we have said <em>reject all\r
+HF spots in the CW section of the bands but accept all others at HF. Also\r
+accept anything in VHF and above spotted in or by operators in the zones\r
+14, 15 and 16</em>. Each filter slot actually has a 'reject' slot and \r
+an 'accept' slot. The reject slot is executed BEFORE the accept slot.\r
+\r
+<P>\r
+It was mentioned earlier that after a reject test that doesn't match, the default \r
+for following tests is 'accept', the reverse is true for 'accept'. In the example \r
+what happens is that the reject is executed first, any non hf/cw spot is passed \r
+to the accept line, which lets through everything else on HF. The next filter line \r
+lets through just VHF/UHF spots from EU.\r
+\r
+<sect1>Basic hop control\r
+\r
+<P>\r
+In /spider/data you will find a file called hop_table.pl. This is the file \r
+that controls your hop count settings. It has a set of default hops on the \r
+various PC frames and also a set for each node you want to alter the hops for. \r
+You may be happy with the default settings of course, but this powerful tool \r
+can help to protect and improve the network. The file will look something \r
+like this ...\r
+\r
+<tscreen><verb>\r
+# \r
+# hop table construction\r
+# \r
+\r
+package DXProt;\r
+\r
+# default hopcount to use\r
+$def_hopcount = 5;\r
+\r
+# some variable hop counts based on message type\r
+%hopcount = \r
+(\r
+ 11 => 10,\r
+ 16 => 10,\r
+ 17 => 10,\r
+ 19 => 10,\r
+ 21 => 10,\r
+);\r
+\r
+\r
+# the per node hop control thingy\r
+\r
+\r
+%nodehops = \r
+\r
+ GB7ADX => { 11 => 8,\r
+ 12 => 8,\r
+ 16 => 8,\r
+ 17 => 8,\r
+ 19 => 8,\r
+ 21 => 8,\r
+ },\r
+\r
+ GB7UDX => { 11 => 8,\r
+ 12 => 8,\r
+ 16 => 8,\r
+ 17 => 8,\r
+ 19 => 8,\r
+ 21 => 8,\r
+ },\r
+ GB7BAA => {\r
+ 11 => 5,\r
+ 12 => 8,\r
+ 16 => 8,\r
+ 17 => 8,\r
+ 19 => 8,\r
+ 21 => 8,\r
+ },\r
+};\r
+</verb></tscreen>\r
+\r
+<P>\r
+Each set of hops is contained within a pair of curly braces and contains a \r
+series of PC frame types. PC11 for example is a DX spot. The figures here \r
+are not exhaustive but should give you a good idea of how the file works.\r
+\r
+<P>\r
+SHould any of the nodecalls include an ssid, it is important to wrap the\r
+whole call in single quotes, like this ...\r
+\r
+<tscreen><verb>\r
+ 'DB0FHF-15' => {\r
+ 11 => 5,\r
+ 12 => 8,\r
+ 16 => 8,\r
+ 17 => 8,\r
+ 19 => 8,\r
+ 21 => 8,\r
+ },\r
+</verb></tscreen>\r
+\r
+If you do not do this, you will get errors and the file will not work as\r
+expected.\r
+\r
+<P>\r
+You can alter this file at any time, including whilst the cluster is running. \r
+If you alter the file during runtime, the command <em>load/hops</em> will \r
+bring your changes into effect.\r
+\r
+<sect1>Hop Control on Specific Nodes\r
+\r
+<p>You can set a callsign specific hop count for any of the standard filter\r
+options so:-\r
+\r
+<tscreen><verb>\r
+set/hops gb7djk spot 4\r
+set/hops node_default route 10\r
+set/hops gb7baa wcy 5\r
+</verb></tscreen>\r
+ \r
+all work on their specific area of the protocol.\r
+\r
+<p>\r
+The <em>set/hops</em> command overrides any hops that you have set otherwise.\r
+\r
+<p>\r
+You can show what hops have been set using the <em>show/hops</em> command.\r
+\r
+<sect1>Isolating networks\r
+\r
+<P>\r
+It is possible to isolate networks from each other on a "gateway" node using the\r
+ <em>set/isolate <node_call></em> command.\r
+ \r
+<P>\r
+The effect of this is to partition an isolated network completely from another \r
+node connected to your node. Your node will appear on and otherwise behave \r
+normally on every network to which you are connected, but data from an isolated \r
+network will not cross onto any other network or vice versa. However all the \r
+spot, announce and WWV traffic and personal messages will still be handled \r
+locally (because you are a real node on all connected networks), that is locally\r
+connected users will appear on all networks and will be able to access and \r
+receive information from all networks transparently. All routed messages will \r
+be sent as normal, so if a user on one network knows that you are a gateway for \r
+another network, he can still still send a talk/announce etc message via your \r
+node and it will be routed across.\r
+\r
+<P>\r
+If you use isolate on a node connection you will continue to receive\r
+all information from the isolated partner, however you will not pass\r
+any information back to the isolated node. There are times when you\r
+would like to forward only spots across a link (maybe during a contest\r
+for example). To do this, isolate the node in the normal way and use\r
+an <em>acc/spot >call< all</em> filter to override the isolate. \r
+\r
+<sect>Other filters\r
+\r
+<sect1>Filtering Mail\r
+\r
+<P>\r
+In the /spider/msg directory you will find a file called badmsg.pl.issue. Rename\r
+this to badmsg.pl and edit the file. The original looks something like this ....\r
+\r
+<tscreen><verb>\r
+\r
+# the list of regexes for messages that we won't store having\r
+# received them (bear in mind that we must receive them fully before\r
+# we can bin them)\r
+\r
+\r
+# The format of each line is as follows\r
+\r
+# type source pattern \r
+# P/B/F T/F/O/S regex \r
+\r
+# type: P - private, B - bulletin (msg), F - file (ak1a bull)\r
+# source: T - to field, F - from field, O - origin, S - subject \r
+# pattern: a perl regex on the field requested\r
+\r
+# Currently only type B and P msgs are affected by this code.\r
+# \r
+# The list is read from the top down, the first pattern that matches\r
+# causes the action to be taken.\r
+\r
+# The pattern can be undef or 0 in which case it will always be selected\r
+# for the action specified\r
+\r
+\r
+\r
+package DXMsg;\r
+\r
+@badmsg = (\r
+'B', 'T', 'SALE', \r
+'B', 'T', 'WANTED',\r
+'B', 'S', 'WANTED',\r
+'B', 'S', 'SALE', \r
+'B', 'S', 'WTB',\r
+'B', 'S', 'WTS',\r
+'B', 'T', 'FS',\r
+);\r
+</verb></tscreen>\r
+\r
+<P>\r
+I think this is fairly self explanatory. It is simply a list of subject \r
+headers that we do not want to pass on to either the users of the cluster or \r
+the other cluster nodes that we are linked to. This is usually because of \r
+rules and regulations pertaining to items for sale etc in a particular country.\r
+\r
+\r
+<sect1>Filtering words from text fields in Announce, Talk and DX spots\r
+\r
+<p>\r
+From version 1.48 onwards the interface to this has changed. You can now\r
+use the commands <em>set/badword</em> to add words that you are not prepared\r
+to see on the cluster, <em>unset/badword</em> to allow that word again and \r
+<em>show/badword</em> to list the words that you have set.\r
+\r
+<p>\r
+If you have a previous <em>/spider/data/badwords</em>, the first time you start\r
+the node, it will read and convert this file to the new commands. The old style\r
+file will then be removed.\r
+\r
+<sect1>Stopping (possibly bad) DX Spots from Nodes or Spotters\r
+\r
+<p> \r
+There are a number of commands that control whether a spot progresses\r
+any further by regarding it as "bad" in some way.\r
+\r
+<p>\r
+A DX Spot has a number of fields which can be checked to see whether they\r
+contain "bad" values, they are: the DX callsign itself, the Spotter and\r
+the Originating Node.\r
+\r
+<p>\r
+There are a set of commands which allow the sysop to control whether a\r
+spot continues:-\r
+\r
+<tscreen><verb>\r
+set/baddx\r
+set/badspotter\r
+set/badnode\r
+</verb></tscreen>\r
+\r
+These work in the same as the <em>set/badword</em> command, you can add\r
+any words or callsigns or whatever to the appropriate database. For\r
+example, to stop a spot from a particular node you do:\r
+\r
+<tscreen><verb>\r
+set/badnode gb7djk gb7dxc\r
+</verb></tscreen>\r
+\r
+a bad spotter:\r
+\r
+<tscreen><verb>\r
+set/badspotter b0mb p1rat nocall\r
+</verb></tscreen>\r
+\r
+and some bad dx:\r
+\r
+<tscreen><verb>\r
+set/baddx video wsjt\r
+</verb></tscreen>\r
+\r
+You can remove a word using the appropriate unset command\r
+(<em>unset/baddx, unset/badspotter, unset/badnode</em>) or list them\r
+using one of <em>show/baddx, show/badspotter</em> and\r
+<em>show/badnode</em>.\r
+\r
+<sect>Mail\r
+\r
+<P>\r
+DXSpider deals seamlessly with standard AK1A type mail. It supports both\r
+personal and bulletin mail and the sysop has additional commands to ensure\r
+that mail gets to where it is meant. DXSpider will send mail almost\r
+immediately, assuming that the target is on line. However, only one\r
+mail message is dealt with at any one time. If a mail message is already\r
+being sent or recieved, then the new message will be queued until it has\r
+finished.\r
+\r
+The cluster mail is automatically deleted after 30 days unless the sysop\r
+sets the "keep" flag using the <em>msg</em> command.\r
+\r
+<sect1>Personal mail\r
+\r
+<P>\r
+Personal mail is sent using the <em>sp</em> command. This is actually the\r
+default method of sending mail and so a simple <em>s</em> for send will do.\r
+A full list of the send commands and options is in the <em>command set</em>\r
+section, so I will not duplicate them here.\r
+\r
+<sect1>Bulletin mail\r
+\r
+<P>\r
+Bulletin mail is sent by using the <em>sb</em> command. This is one of the\r
+most common mistakes users make when sending mail. They send a bulletin\r
+mail with <em>s</em> or <em>sp</em> instead of <em>sb</em> and of course\r
+the message never leaves the cluster. This can be rectified by the sysop\r
+by using the <em>msg</em> command.\r
+\r
+<P>Bulletin addresses can be set using the Forward.pl file.\r
+\r
+<sect1>Forward.pl\r
+\r
+<P>\r
+DXSpider receives all and any mail sent to it without any alterations needed\r
+in files. Because personal and bulletin mail are treated differently, there\r
+is no need for a list of accepted bulletin addresses. It is necessary, however,\r
+to tell the program which links accept which bulletins. For example, it is\r
+pointless sending bulletins addresses to "UK" to any links other than UK\r
+ones. The file that does this is called forward.pl and lives in /spider/msg.\r
+At default, like other spider files it is named forward.pl.issue. Rename it\r
+to forward.pl and edit the file to match your requirements.\r
+The format is below ...\r
+\r
+<tscreen><verb>\r
+#\r
+# this is an example message forwarding file for the system\r
+#\r
+# The format of each line is as follows\r
+#\r
+# type to/from/at pattern action destinations\r
+# P/B/F T/F/A regex I/F [ call [, call ...] ]\r
+#\r
+# type: P - private, B - bulletin (msg), F - file (ak1a bull)\r
+# to/from/at: T - to field, F - from field, A - home bbs, O - origin \r
+# pattern: a perl regex on the field requested\r
+# action: I - ignore, F - forward\r
+# destinations: a reference to an array containing node callsigns\r
+#\r
+# if it is non-private and isn't in here then it won't get forwarded \r
+#\r
+# Currently only type B msgs are affected by this code.\r
+# \r
+# The list is read from the top down, the first pattern that matches\r
+# causes the action to be taken.\r
+#\r
+# The pattern can be undef or 0 in which case it will always be selected\r
+# for the action specified\r
+#\r
+# If the BBS list is undef or 0 and the action is 'F' (and it matches the\r
+# pattern) then it will always be forwarded to every node that doesn't have \r
+# it (I strongly recommend you don't use this unless you REALLY mean it, if\r
+# you allow a new link with this on EVERY bull will be forwarded immediately\r
+# on first connection)\r
+#\r
+\r
+package DXMsg;\r
+\r
+@forward = (\r
+'B', 'T', 'LOCAL', 'F', [ qw(GB7MBC) ],\r
+'B', 'T', 'ALL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'UK', 'F', [ qw(GB7BAA GB7ADX) ],\r
+'B', 'T', 'QSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'QSLINF', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'DX', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'DXINFO', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'DXNEWS', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'DXQSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'SYSOP', 'F', [ qw(GB7BAA GB7ADX) ],\r
+'B', 'T', '50MHZ', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+);\r
+</verb></tscreen>\r
+\r
+Simply insert a bulletin address and state in the brackets where you wish\r
+that mail to go. For example, you can see here that mail sent to "UK" will\r
+only be sent to the UK links and not to PA4AB-14.\r
+\r
+<P>\r
+To force the cluster to reread the file use load/forward\r
+\r
+<P>\r
+NB: If a user tries to send mail to a bulletin address that does not exist\r
+in this file, they will get an error.\r
+\r
+<sect1>The msg command\r
+\r
+<P>\r
+The <em>msg</em> command is a very powerful and flexible tool for the\r
+sysop. It allows the sysop to alter to and from fields and make other\r
+changes to manage the cluster mail.\r
+\r
+Here is a full list of the various options ...\r
+\r
+<tscreen><verb>\r
+ MSG TO <msgno> <call> - change TO callsign to <call>\r
+ MSG FRom <msgno> <call> - change FROM callsign to <call>\r
+ MSG PRrivate <msgno> - set private flag\r
+ MSG NOPRrivate <msgno> - unset private flag\r
+ MSG RR <msgno> - set RR flag\r
+ MSG NORR <msgno> - unset RR flag\r
+ MSG KEep <msgno> - set the keep flag (message won't be deleted ever)\r
+ MSG NOKEep <msgno> - unset the keep flag\r
+ MSG SUbject <msgno> <new> - change the subject to <new>\r
+ MSG WAittime <msgno> - remove any waiting time for this message\r
+ MSG NOREad <msgno> - mark message as unread\r
+ MSG REad <msgno> - mark message as read\r
+ MSG QUeue - queue any outstanding bulletins\r
+ MSG QUeue 1 - queue any outstanding private messages\r
+</verb></tscreen>\r
+\r
+These commands are simply typed from within the cluster as the sysop user.\r
+\r
+<sect1>Message status\r
+\r
+<P>\r
+You can check on a message from within the cluster by using the command\r
+<em>stat/msg</em>. This will give you additional information on the\r
+message number including which nodes have received it, which node it\r
+was received from and when etc. Here is an example of the output of\r
+the command ...\r
+\r
+<tscreen><verb>\r
+G0VGS de GB7MBC 28-Jan-2001 1308Z >\r
+stat/msg 6869\r
+ From: GB7DJK\r
+ Msg Time: 26-Jan-2001 1302Z\r
+ Msgno: 6869\r
+ Origin: GB7DJK\r
+ Size: 8012\r
+ Subject: AMSAT 2line KEPS 01025.AMSAT\r
+ To: UK\r
+Got it Nodes: GB7BAA, GB7ADX\r
+ Private: 0\r
+Read Confirm: 0\r
+ Times read: 0\r
+G0VGS de GB7MBC 28-Jan-2001 1308Z >\r
+</verb></tscreen>\r
+\r
+<sect1>Filtering mail\r
+\r
+<P>\r
+This is described in the section on <em>Other filters</em> so I will not\r
+duplicate it here.\r
+\r
+<sect1>Distribution lists\r
+\r
+<P>\r
+Distribution lists are simply a list of users to send certain types of\r
+mail to. An example of this is mail you only wish to send to other\r
+sysops. In /spider/msg there is a directory called <em>distro</em>. You\r
+put any distibution lists in here. For example, here is a file called\r
+SYSOP.pl that caters for the UK sysops.\r
+\r
+<tscreen><verb>\r
+qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX\r
+ GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH \r
+ GB7DXK GB7DXI GB7DXS)\r
+</verb></tscreen>\r
+\r
+Any mail sent to "sysop" would only be sent to the callsigns in this list.\r
+\r
+<sect1>BBS interface\r
+\r
+<P>\r
+Spider provides a simple BBS interface. No input is required from the sysop\r
+of the cluster at all. The BBS simply sets the cluster as a BBS and pushes\r
+any required mail to the cluster. No mail can flow from Spider to the BBS,\r
+the interface is one-way.\r
+\r
+<P>\r
+Please be careful not to flood the cluster network with unnecessary mail.\r
+Make sure you only send mail to the clusters that want it by using the\r
+Forward.pl file very carefully.\r
+\r
+<sect>Scripts\r
+\r
+<p>\r
+From 1.48 onwards it will become increasingly possible to control DXSpider's\r
+operation with scripts of various kinds.\r
+\r
+<P>\r
+The directory /spider/scripts is where it all happens and is used for several \r
+things. Firstly it contains a file called startup that can be used to call \r
+in any changes to the cluster from the default settings on startup. This\r
+script is executed immediately after all initialisation of the node is done\r
+but before any connections are possible. Examples of this include how many \r
+spots it is possible to get with the sh/dx command, whether you want \r
+registration/passwords to be permanently on etc. An example file is shown \r
+below and is included in the distribution as startup.issue.\r
+\r
+<tscreen><verb>\r
+#\r
+# startup script example\r
+#\r
+# set maximum no of spots allowed to 100\r
+# set/var $Spot::maxspots = 100\r
+#\r
+# Set registration on\r
+# set/var $main::reqreg = 1\r
+#\r
+# Set passwords on\r
+# set/var $main::passwdreq = 1\r
+#\r
+</verb></tscreen>\r
+\r
+<P>\r
+As usual, any text behind a # is treated as a comment and not read. To use\r
+this file, simply rename it from startup.issue to startup. In our example\r
+above there are three options. The first option is the amount of spots that\r
+a user can request with the <em>sh/dx</em> command. Normally the default is\r
+to give 10 spots unless the user specifies more. Without this line enabled,\r
+the maximum a user can request is 100 spots. Depending on your link quality\r
+you may wish to enable more or less by specifying the number.\r
+\r
+<P>\r
+The other 2 options are dealt with more fully in the security section.\r
+\r
+<P>\r
+Secondly, it is used to store the login scripts for users and nodes. Currently\r
+this can only be done by the sysop but it is envisaged that eventually users will \r
+be able to set their own. An example is included in the distibution but here is \r
+a further example.\r
+\r
+<tscreen><verb>\r
+#\r
+# G0FYD\r
+#\r
+blank +\r
+sh/wwv 3\r
+blank +\r
+sh/dx \r
+blank +\r
+t g0jhc You abt?\r
+blank +\r
+</verb></tscreen>\r
+\r
+The lines in between commands can simply insert a blank line or a character\r
+such as a + sign to make the output easier to read. Simply create this script\r
+with your favourite editor and save it with the callsign of the user as the\r
+filename. Filenames should always be in lower case.\r
+\r
+<P>\r
+Commands can be inserted in the same way for nodes. A node may wish a series\r
+of commands to be issued on login, such as a merge command for example.\r
+\r
+<P>\r
+Thirdly, there are 2 default scripts for users and nodes who do not have a\r
+specifically defined script. These are <em>user_default</em> and\r
+<em>node_default</em>\r
+\r
+<sect>Databases\r
+\r
+<P>\r
+Spider allows the creation of local or remote databases. It supports\r
+chained databases, allowing several different databases to be scanned\r
+with one simple command. Importing of databases is limited at present\r
+to the standard AK1A databases such as OBLAST and the DB0SDX QSL \r
+database but will expand with time.\r
+\r
+<sect1>Creating databases\r
+\r
+<P>\r
+Creating a database could not be more simple. All the commands are\r
+sent from the cluster prompt as the <em>sysop</em> user.\r
+\r
+To create a database you use the command <em>dbcreate</em>. It can\r
+be used in 3 different ways like so ..\r
+\r
+<tscreen><verb>\r
+dbcreate <name>\r
+</verb></tscreen>\r
+\r
+To simply create a database locally, you just tell the command the\r
+name of the database. This does not create the actual database, it\r
+simply defines it to say that it exists.\r
+\r
+<tscreen><verb>\r
+dbcreate <name> chain <name> [<name>...]\r
+</verb></tscreen>\r
+\r
+This creates a chained database entry. The first database will be\r
+scanned, then the second, the third etc...\r
+\r
+<tscreen><verb>\r
+dbcreate <name> remote <name>\r
+</verb></tscreen>\r
+\r
+This creates a remote entry. the first name field is the database\r
+name at the remote node, then the remote switch, then the actual\r
+node_call of the remote node, for example...\r
+\r
+<tscreen><verb>\r
+dbcreate buckmaster remote gb7dxc\r
+</verb></tscreen>\r
+\r
+Remote databases cannot be chained, however, the last database in a\r
+chain can be a remote database.\r
+\r
+<sect1>Importing databases\r
+\r
+<P>\r
+The only databases that Spider can currently import are the standard\r
+AK1A databases such as OBLAST or the DB0SDX qsl and address database.\r
+This will be added to with time.\r
+\r
+To import such a database, first put the file somewhere useful like /tmp\r
+and then issue the following command ...\r
+\r
+<tscreen><verb>\r
+dbimport oblast /tmp/OBLAST.FUL\r
+</verb></tscreen>\r
+\r
+This will update the existing local oblast database or create it if\r
+it does not exist.\r
+\r
+<sect1>Checking available databases\r
+\r
+<P>\r
+Once a database is created, you will want to check that it has been\r
+added. To do this use the <em>dbavail</em> command. This will\r
+output the available databases. For example ...\r
+\r
+<tscreen><verb>\r
+dbavail\r
+DB Name Location Chain\r
+qsl Local\r
+buck GB7ADX\r
+hftest GB7DXM\r
+G0VGS de GB7MBC 3-Feb-2001 1925Z >\r
+</verb></tscreen>\r
+\r
+<sect1>Looking up databases\r
+\r
+<P>\r
+To look for information in a defined database, simply use the <em>dbshow</em>\r
+command, for example ...\r
+\r
+<tscreen><verb>\r
+dbshow buckmaster G0YLM\r
+</verb></tscreen>\r
+\r
+will show the information for the callsign G0YLM from the buckmaster\r
+database if it exists. To make things more standard for the users\r
+you can add an entry in the Aliases file so that it looks like a standard \r
+<em>show</em> command like this ...\r
+\r
+<tscreen><verb>\r
+'^sh\w*/buc', 'dbshow buckmaster', 'dbshow',\r
+</verb></tscreen>\r
+\r
+Now you can simply use show/buckmaster or an abreviation.\r
+\r
+<sect1>Removing databases\r
+\r
+<P>\r
+To delete an existing database you use the <em>dbremove</em> command.\r
+For example ...\r
+\r
+<tscreen><verb>\r
+dbremove oblast\r
+</verb></tscreen>\r
+\r
+would remove the oblast database and its associated datafile from the\r
+system. There are no warnings or recovery possible from this command.\r
+If you remove a database it ceases to exist and would have to be created\r
+from scratch if you still required it.\r
+\r
+<sect>Information, files and useful programs\r
+\r
+<sect1>MOTD\r
+\r
+<P>\r
+One of the more important things a cluster sysop needs to do is to get \r
+information to his users. The simplest way to do this is to have a banner \r
+that is sent to the user on login. This is know as a "message of the day" \r
+or "motd". To set this up, simply create a file in /spider/data called motd \r
+and edit it to say whatever you want. It is purely a text file and will be \r
+sent automatically to anyone logging in to the cluster.\r
+\r
+<sect1>MOTD_NOR\r
+\r
+<P>\r
+This message of the day file lives in the same directory as the standard\r
+motd file but is only sent to non-registered users. Once registered they\r
+will receive the same message as any other user.\r
+\r
+<sect1>Downtime message\r
+\r
+<P>\r
+If for any reason the cluster is down, maybe for upgrade or maintenance but \r
+the machine is still running, a message can be sent to the user advising them \r
+of the fact. This message lives in the /spider/data directory and is called\r
+"offline". Simply create the file and edit it to say whatever you wish. \r
+This file will be sent to a user attempting to log into the cluster when\r
+DXSpider is not actually running.\r
+\r
+<sect1>Other text messages\r
+\r
+<P>\r
+You can set other text messages to be read by the user if they input the file \r
+name. This could be for news items or maybe information for new users. \r
+To set this up, make a directory under /spider called <em>packclus</em>. \r
+Under this directory you can create files called <em>news</em> or <em>newuser</em>\r
+for example. In fact you can create files with any names you like. These can \r
+be listed by the user with the command ....\r
+\r
+<tscreen><verb>\r
+show/files\r
+</verb></tscreen>\r
+\r
+They can be read by the user by typing the command ....\r
+\r
+<tscreen><verb>\r
+type news\r
+</verb></tscreen>\r
+\r
+If the file they want to read is called <em>news</em>. You could also set \r
+an alias for this in the Alias file to allow them just to type <em>news</em>\r
+\r
+<P>\r
+You can also store other information in this directory, either directly or \r
+nested under directories. One use for this would be to store DX bulletins \r
+such as the OPDX bulletins. These can be listed and read by the user. \r
+To keep things tidy, make a directory under /spider/packclus called\r
+<em>bulletin</em>. Now copy any OPDX or similar bulletins into it. These \r
+can be listed by the user in the same way as above using the <em>show/files</em>\r
+command with an extension for the bulletin directory you have just created, \r
+like this ....\r
+\r
+<tscreen><verb>\r
+show/files bulletin\r
+</verb></tscreen>\r
+\r
+<P>\r
+An example would look like this ....\r
+\r
+<tscreen><verb>\r
+sh/files\r
+bulletin DIR 20-Dec-1999 1715Z news 1602 14-Dec-1999 1330Z\r
+</verb></tscreen>\r
+\r
+You can see that in the files area (basically the packclus directory) there is a \r
+file called <em>news</em> and a directory called <em>bulletin</em>. You can \r
+also see that dates they were created. In the case of the file <em>news</em>, \r
+you can also see the time it was last modified, a good clue as to whether the \r
+file has been updated since you last read it. To read the file called \r
+<em>news</em> you would simply issue the command ....\r
+\r
+<tscreen><verb>\r
+type news\r
+</verb></tscreen>\r
+\r
+To look what is in the bulletin directory you issue the command ....\r
+\r
+<tscreen><verb>\r
+show/files bulletin\r
+opdx390 21381 29-Nov-1999 1621Z opdx390.1 1670 29-Nov-1999 1621Z\r
+opdx390.2 2193 29-Nov-1999 1621Z opdx391 25045 29-Nov-1999 1621Z \r
+opdx392 35969 29-Nov-1999 1621Z opdx393 15023 29-Nov-1999 1621Z \r
+opdx394 33429 29-Nov-1999 1621Z opdx394.1 3116 29-Nov-1999 1621Z \r
+opdx395 24319 29-Nov-1999 1621Z opdx396 32647 29-Nov-1999 1621Z\r
+opdx396.1 5537 29-Nov-1999 1621Z opdx396.2 6242 29-Nov-1999 1621Z\r
+opdx397 18433 29-Nov-1999 1621Z opdx398 19961 29-Nov-1999 1621Z \r
+opdx399 17719 29-Nov-1999 1621Z opdx400 19600 29-Nov-1999 1621Z\r
+opdx401 27738 29-Nov-1999 1621Z opdx402 18698 29-Nov-1999 1621Z\r
+opdx403 24994 29-Nov-1999 1621Z opdx404 15685 29-Nov-1999 1621Z\r
+opdx405 13984 29-Nov-1999 1621Z opdx405.1 4166 29-Nov-1999 1621Z\r
+opdx406 28934 29-Nov-1999 1621Z opdx407 24153 29-Nov-1999 1621Z\r
+opdx408 15081 29-Nov-1999 1621Z opdx409 23234 29-Nov-1999 1621Z\r
+Press Enter to continue, A to abort (16 lines) >\r
+</verb></tscreen>\r
+\r
+You can now read any file in this directory using the type command, like this ....\r
+\r
+<tscreen><verb>\r
+type bulletin/opdx391\r
+Ohio/Penn DX Bulletin No. 391\r
+The Ohio/Penn Dx PacketCluster\r
+DX Bulletin No. 391\r
+BID: $OPDX.391\r
+January 11, 1999\r
+Editor Tedd Mirgliotta, KB8NW\r
+Provided by BARF-80 BBS Cleveland, Ohio\r
+Online at 440-237-8208 28.8k-1200 Baud 8/N/1 (New Area Code!)\r
+Thanks to the Northern Ohio Amateur Radio Society, Northern Ohio DX\r
+Association, Ohio/Penn PacketCluster Network, K1XN & Golist, WB2RAJ/WB2YQH\r
+& The 59(9) DXReport, W3UR & The Daily DX, K3TEJ, KN4UG, W4DC, NC6J, N6HR,\r
+Press Enter to continue, A to abort (508 lines) >\r
+</verb></tscreen>\r
+\r
+The page length will of course depend on what you have it set to!\r
+\r
+<sect1>The Aliases file\r
+\r
+<P>\r
+You will find a file in /spider/cmd/ called Aliases. This is the file that\r
+controls what a user gets when issuing a command. It is also possible to\r
+create your own aliases for databases and files you create locally.\r
+\r
+<P>\r
+You should not alter the original file in /spider/cmd/ but create a new file\r
+with the same name in /spider/local_cmd. This means that any new Aliases files\r
+that is downloaded will not overwrite your self created Aliases and also that\r
+you do not override any new Aliases with your copy in /spider/local_cmd/. You\r
+must remember that any files you store in /spider/local/ or /spider/local_cmd\r
+override the originals if the same lines are used in both files.\r
+\r
+<P>\r
+The best way of dealing with all this then is to only put your own locally\r
+created Aliases in the copy in /spider/local_cmd. The example below is\r
+currently in use at GB7MBC.\r
+\r
+<tscreen><verb>\r
+\r
+#\r
+# Local Aliases File\r
+#\r
+\r
+package CmdAlias;\r
+\r
+%alias = (\r
+ 'n' => [\r
+ '^news$', 'type news', 'type',\r
+ ],\r
+ 's' => [\r
+ '^sh\w*/buck$', 'show/qrz', 'show',\r
+ '^sh\w*/hftest$', 'dbshow hftest', 'dbshow',\r
+ '^sh\w*/qsl$', 'dbshow qsl', 'dbshow',\r
+ '^sh\w*/vhf$', 'dbshow vhf', 'dbshow',\r
+ '^sh\w*/vhftest$', 'dbshow vhftest', 'dbshow',\r
+ ],\r
+)\r
+\r
+</verb></tscreen>\r
+\r
+<P>\r
+Each alphabetical section should be preceded by the initial letter and the section\r
+should be wrapped in square brackets as you can see. The syntax is straightforward.\r
+The first section on each line is the new command that will be allowed once the\r
+alias is included. The second section is the command it is replacing and the last\r
+section is the actual command that is being used.\r
+\r
+<P>\r
+The eagle-eyed amongst you will have noticed that in the first section, the new\r
+alias command has a '^' at the start and a '$' at the end. Basically these force\r
+a perfect match on the alias. The '^' says match the beginning exactly and the\r
+'$' says match the end exactly. This prevents unwanted and unintentional matches\r
+with similar commands.\r
+\r
+<P>\r
+I have 3 different types of alias in this file. At the top is an alias for 'news'. \r
+This is a file I have created in the /spider/packclus/ directory where I can inform \r
+users of new developments or points of interest. In it's initial form a user would \r
+have to use the command <em>type news</em>. The alias allows them to simply type \r
+<em>news</em> to get the info. Second is an alias for the <em>show/qrz</em>\r
+command so that those users used to the original <em>show/buck</em> command in\r
+AK1A will not get an error, and the rest of the lines are for locally created\r
+databases so that a user can type <em>show/hftest</em> instead of having to use\r
+the command <em>dbshow hftest</em> which is not as intuitive.\r
+\r
+<P>\r
+This file is just an example and you should edit it to your own requirements.\r
+Once created, simply issue the command <em>load/alias</em> at the cluster\r
+prompt as the sysop user and the aliases should be available.\r
+\r
+\r
+<sect1>Console.pl\r
+\r
+<P>\r
+In later versions of Spider a simple console program is provided for the sysop. \r
+This has a type ahead buffer with line editing facilities and colour for spots,\r
+announces etc. To use this program, simply use console.pl instead of client.\r
+\r
+<P>\r
+To edit the colours, copy /spider/perl/Console.pl to /spider/local and edit the \r
+file with your favourite editor.\r
+\r
+<sect1>Updating kepler data\r
+\r
+<P>\r
+Spider has a powerful and flexible show/satellite command. In order for\r
+this to be accurate, the kepler data has to be updated regularly. In\r
+general, this data is available as an email or via cluster mail.\r
+Updating it is simple. First you need to export the mail message as a\r
+file. You do this with the <em>export</em> command from the cluster prompt\r
+as the sysop. For example ...\r
+\r
+<tscreen><verb>\r
+export 5467 /spider/perl/keps.in\r
+</verb></tscreen>\r
+\r
+<P>\r
+would export message number 5467 as a file called keps.in in the\r
+/spider/perl directory.\r
+\r
+<P>\r
+Now login to a VT as sysop and cd /spider/perl. There is a command in\r
+the perl directory called <em>convkeps.pl</em>. All we need to do now is\r
+convert the file like so ...\r
+\r
+<tscreen><verb>\r
+./convkeps.pl keps.in\r
+</verb></tscreen>\r
+\r
+<P>\r
+Now go back to the cluster and issue the command ...\r
+\r
+<tscreen><verb>\r
+load/keps\r
+</verb></tscreen>\r
+\r
+<P>\r
+That is it! the kepler data has been updated.\r
+\r
+<sect1>The QRZ callbook\r
+\r
+<P>\r
+The command <em>sh/qrz</em> will only work once you have followed a few\r
+simple steps. First you need to get a user ID and password from qrz.com.\r
+Simply go to the site and create one. Secondly you need to copy the file\r
+/spider/perl/Internet.pm to /spider/local and alter it to match your user\r
+ID and password. You also at this point need to set $allow=1 to complete\r
+the setup. Many thanks to Fred Lloyd, the proprieter of\r
+<htmlurl url="http://www.qrz.com" name="qrz.com"> for allowing this access.\r
+\r
+<sect1>Connecting logging programs\r
+\r
+<P>\r
+There appear to be very few logging programs out there that support telnet\r
+especially the popular ones like LogEQF, Turbolog etc. This can make it\r
+difficult to connect to your own cluster!\r
+The way to do it is to make the logging program think it has a TNC attached\r
+to a com port on the logging PC and 'push' a linux login out to it.\r
+This is achieved very simply by the use of <em>agetty</em>.\r
+\r
+<P>\r
+All that is required is to add a line in /etc/inittab to have the client\r
+ready for a connection on the com port of your choice. Remember that in\r
+Linux, the com ports start at ttyS0 for com1, ttyS1 for com2 etc.\r
+\r
+<tscreen><verb>\r
+c4:2345:respawn:/sbin/agetty -L 9600 ttyS1\r
+</verb></tscreen>\r
+\r
+<P>\r
+Add this after the standard runlevel lines in /etc/inittab. The above\r
+line works on ttyS1 (com2). Now as root, issue the command <em>telinit q</em>\r
+and it should be ready for connection. All that is required is a 3 wire\r
+serial lead (tx, rx and signal ground). Tell you logging program to use\r
+8n1 at 9600 baud and you should see a Linux login prompt. Login as normal\r
+and then telnet from there to the cluster.\r
+\r
+<sect>Java Web applet\r
+\r
+<P>\r
+In the spider tree will be a directory <em>spider-web</em>. This is a\r
+neat little java web applet that can be run from a website. The applet\r
+must run on the same machine as the cluster. The included README file is\r
+shown below.\r
+\r
+<P>\r
+I should comment here that the applet is precompiled, that is, ready to go.\r
+It was compiled using JDK1.3.1. If your version is earlier than this then it\r
+may not work. Should that be the case you need to recompile or update your\r
+JDK. To recompile do the following ...\r
+\r
+<tscreen><verb>\r
+cd /spider/spider-web\r
+rm *.class\r
+/usr/bin/javac spiderclient.java\r
+</verb></tscreen>\r
+\r
+<P>\r
+I have used /usr/bin/javac as an example, your path to javac may be different.\r
+\r
+<verb>\r
+Spider-WEB v0.6b\r
+\r
+Completely based on a clx web client written in Java by dl6dbh\r
+(ftp://clx.muc.de/pub/clx/clx-java_10130001.tgz)\r
+\r
+The webserver has to run on the same machine as your DxSpider software!\r
+\r
+It is assumed that you have Java installed. You need JDK1.3.1 at least.\r
+\r
+Installation instructions (Performed as root):\r
+\r
+Put all the files in the spider-web directory into a newly created directory\r
+under the DocumentRoot of your websever for instance 'client'. In my case\r
+this is: /home/httpd/html/client/ although ymmv. For Suse the correct\r
+path should be /usr/local/httpd/htdocs/client/ for example.\r
+\r
+Move spider.cgi to the cgi-bin directory of your webserver, in my case that is\r
+/home/httpd/cgi-bin/ although ymmv. For Suse the correct path should be\r
+/usr/local/httpd/cgi-bin/ for example.\r
+\r
+Change the permissions of the files to ensure they are correct, obviously you\r
+will need to use the correct path the the files according to your system:\r
+\r
+chmod 755 /home/httpd/html/cgi-bin/spider.cgi\r
+chmod -R 755 /home/httpd/html/client/\r
+\r
+By default the spider.cgi script should pick up your hostname (As long as this\r
+is set correctly). If it does not or your hostname differs from the name that\r
+you attach to the public address that you are using, then edit spider.cgi :\r
+\r
+# Uncomment and set the hostname manually here if the above fails.\r
+# $HOSTNAME = "gb7mbc.spoo.org" ;\r
+$PORT = "8000" ;\r
+\r
+'HOSTNAME' is the hostname of your cluster.\r
+\r
+'PORT' is the portnumber that you use to connect to your DxSpider via\r
+telnet (see Listeners.pm)\r
+\r
+NOTE: If you can start the console but cannot connect to the cluster from it,\r
+then it is possible that the machine you are on cannot resolve the hostname of \r
+your cluster machine. If this is the case, you need to set your hostname \r
+manually as above.\r
+\r
+You also need to set the $NODECALL variable. This prints the name of your\r
+choosing (probably your cluster callsign) on the html page.\r
+\r
+You now can connect to Spider-Web via http://yourserver/cgi-bin/spider.cgi\r
+</verb>\r
+\r
+<sect>Security\r
+\r
+<P>\r
+From version 1.49 DXSpider has some additional security features. These\r
+are not by any means meant to be exhaustive, however they do afford some\r
+security against piracy. These two new features can be used independently \r
+of each other or in concert to tighten the security.\r
+\r
+<sect1>Registration\r
+\r
+<P>\r
+The basic principle of registration is simple. If a user is not registered\r
+by the sysop, then they have read-only access to the cluster. The only\r
+thing they can actually send is a talk or a message to the sysop. In\r
+order for them to be able to spot, send announces or talks etc the sysop\r
+must register them with the <em>set/register</em> command, like this ...\r
+\r
+<tscreen><verb>\r
+set/register g0vgs\r
+</verb></tscreen>\r
+\r
+The user g0vgs can now fully use the cluster. In order to enable \r
+registration, you can issue the command ...\r
+\r
+<tscreen><verb>\r
+set/var $main::reqreg = 1\r
+</verb></tscreen>\r
+\r
+Any users that are not registered will now see the motd_nor file rather\r
+than the motd file as discussed in the Information, files and useful \r
+programs section.\r
+\r
+<P>\r
+Entering this line at the prompt will only last for the time the cluster\r
+is running of course and would not be present on a restart. To make the\r
+change permanent, add the above line to /spider/scripts/startup. To\r
+read more on the startup file, see the section on Information, files \r
+and useful programs.\r
+\r
+<P>\r
+To unregister a user use <em>unset/register</em> and to show the list\r
+of registered users, use the command <em>show/register</em>.\r
+\r
+<sect1>Passwords\r
+\r
+<P>\r
+At the moment, passwords only affect users who login to a DXSpider\r
+cluster node via telnet. If a user requires a password, they can\r
+either set it themselves or have the sysop enter it for them by using\r
+the <em>set/password</em> command. Any users who already have passwords, \r
+such as remote sysops, will be asked for their passwords automatically \r
+by the cluster. Using passwords in this way means that the user has a\r
+choice on whether to have a password or not. To force the use of\r
+passwords at login, issue the command ...\r
+\r
+<tscreen><verb>\r
+set/var $main::passwdreq = 1\r
+</verb></tscreen>\r
+\r
+at the cluster prompt. This can also be added to the /spider/scripts/startup\r
+file as above to make the change permanent.\r
+\r
+<P>\r
+Of course, if you do this you will have to assign a password for each of \r
+your users. If you were asking them to register, it is anticipated that\r
+you would ask them to send you a message both to ask to be registered and\r
+to give you the password they wish to use.\r
+\r
+<P>\r
+Should a user forget their password, it can be reset by the sysop by\r
+first removing the existing password and then setting a new one like so ...\r
+\r
+<tscreen><verb>\r
+unset/password g0vgs\r
+set/password g0vgs new_password\r
+</verb></tscreen>\r
+\r
+<sect>CVS\r
+\r
+<sect1>CVS from a Linux platform\r
+\r
+<P>\r
+CVS stands for "Concurrent Versions System" and the CVS for DXSpider is held\r
+at <htmlurl url="http://www.sourceforge.net" name="Sourceforge">. This means\r
+that it is possible to update your DXSpider installation to the latest\r
+sources by using a few simple commands. A graphical interface to CVS for\r
+Windows is explained in the next section.\r
+\r
+<P>\r
+Please be aware that if you update your system using CVS, it is possible that\r
+you could be running code that is very beta and not fully tested. There is\r
+a possibility that it could be unstable.\r
+\r
+<P>\r
+I am of course assuming that you have a machine with both DXSpider and\r
+Internet access running.\r
+\r
+<P>\r
+BEFORE YOU EVEN CONSIDER STARTING WITH THIS MAKE A BACKUP OF YOUR\r
+ENTIRE SPIDER TREE!!\r
+\r
+<P>\r
+Assuming you are connected to the Internet, you need to login to the\r
+CVS repository and then update your Spider source. There are several\r
+steps which are listed below ...\r
+\r
+<P>\r
+First login as the user <em>sysop</em>. Next you need to connect to the CVS\r
+repository. You do this with the command below ...\r
+\r
+<verb>\r
+cvs -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login\r
+</verb>\r
+\r
+You will get a password prompt. Simply hit return here and your machine should\r
+return to a normal linux prompt.\r
+\r
+<P>\r
+What happens next depends on whether you have an existing installation that\r
+you want to update with the latest and greatest or whether you just want\r
+to see what is there and/or run it on a new machine for testing.\r
+\r
+If you are installing Spider from CVS then change directory to /home/sysop\r
+\r
+If you are wanting to update Spider then cd to /tmp\r
+\r
+<P>\r
+The next step will create a brand new 'spider' directory in your current\r
+directory.\r
+\r
+<verb>\r
+cvs -z3 -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider co spider\r
+</verb>\r
+\r
+This command is all on one line.\r
+\r
+<P>\r
+Hopefully your screen should show you downloading files. The -z3 simply compresses\r
+the download to improve speed.\r
+When this has finished, you will have exactly the same as if you had untarred a full\r
+tarball PLUS some extra directories and files that CVS needs to do the magic that\r
+it does.\r
+\r
+<P>\r
+Now if you are doing a new installation, that's it. Carry on as if you have\r
+just downloaded and untarred the lastest tarball.\r
+\r
+<P>\r
+If you want to upgrade your current installation then do this ...\r
+\r
+<tscreen><verb>\r
+tar cvfz /tmp/s.tgz spider\r
+cd /\r
+tar xvfzp /tmp/s.tgz\r
+</verb></tscreen>\r
+\r
+This is assuming you downloaded to the /tmp directory of course.\r
+\r
+<P>\r
+NOTE: the 'p' on the end of the 'xvfz' is IMPORTANT! It keeps the permissions\r
+correct. YOU WERE LOGGED IN AS THE USER SYSOP WEREN'T YOU?????\r
+\r
+Remember to recompile the C client (cd /spider/src; make)\r
+\r
+<P>\r
+At this point the files have been upgraded. You can (usually) restart the cluster\r
+in your own time. However, if you attempt to use any new commands or features\r
+expect it to be fatal! At least your cluster will have been restarted then so it\r
+will be too late to worry about it!\r
+\r
+<P>\r
+Now the magic part! From now on when you want to update, simply connect to the\r
+Internet and then, as the user <em>sysop</em> ...\r
+\r
+<tscreen><verb>\r
+cd /spider\r
+cvs -z3 update -d\r
+</verb></tscreen>\r
+\r
+and your files will be updated. As above, remember to recompile the "C" client\r
+if it has been updated (CVS will tell you) and restart if any of the perl scripts\r
+have been altered or added, again, CVS will tell you.\r
+\r
+<P>\r
+You will find any changes documented in the /spider/Changes file.\r
+\r
+<sect1>CVS from a Windows platform\r
+\r
+<P>\r
+After the initial setup, an update to your DXSpider software is no more than a couple\r
+of clicks away. This section is intended to explain and illustrate the use of the\r
+WinCVS application to update your DXSpider software. The current stable version of\r
+WinCVS is Ver. 1.2. You can get this software at:\r
+\r
+<htmlurl url="http://prdownloads.sourceforge.net/cvsgui/WinCvs120.zip" name="http://prdownloads.sourceforge.net/cvsgui/WinCvs120.zip">\r
+\r
+Pick your download mirror and then install WinCVS after the download is complete.\r
+\r
+In this next section I have included a series of links to .jpg files to take advantage of the\r
+picture and 1000 words equivalency. The .jpg files are in the C:\spider\html directory. If\r
+someone using a Linux system is reading this section from boredom, the files are in\r
+/home/sysop/spider/html. One aside, a Linux user can also get a copy of gcvs and do your updates\r
+graphically as opposed to from the command line. The following descriptions are almost identical\r
+between WinCvs and gcvs. The following screen shots have duplicate links, depending upon whether\r
+you are viewing this information under the Windows or Linux operating system.\r
+\r
+When WinCVS is installed, running, and you are connected to the internet, the initial screen looks like:\r
+\r
+<htmlurl url="initial.jpg" name="initial.jpg">\r
+\r
+If you want, you can also look at these .jpg files with another viewer that might provide some\r
+better clarity to the image. On the left is the directory tree for your hard disk. Notice that\r
+the spider directory has a gray highlight.\r
+\r
+To start configuring WinCVS, click on Admin at the top of the screen and then Preferences. This \r
+should get you:\r
+\r
+<htmlurl url="pref-gen.jpg" name="pref-gen.jpg">\r
+\r
+In the top line for CVSROOT, enter:\r
+<tscreen><verb>\r
+anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login\r
+</verb></tscreen>\r
+\r
+and select\r
+<tscreen><verb>\r
+"passwd" file on the cvs server\r
+</verb></tscreen>\r
+\r
+for Authentication on the General tab.\r
+\r
+Next, move to the right to the Ports tab.\r
+\r
+<htmlurl url="pref-ports.jpg" name="pref-ports.jpg">\r
+\r
+In here, check the box on the second line down for the "pserver" port. Enter a port number of 2401.\r
+\r
+Finally, go to the WinCvs tab all the way to the right.\r
+\r
+<htmlurl url="pref-wincvs.jpg" name="pref-wincvs.jpg">\r
+\r
+Enter Notepad as the viewer to open files. For the HOME folder, put "C:\spider" and click OK\r
+because the configuration is now complete.\r
+\r
+You are now ready to upgrade your copy of DXSpider. Click on the greyed Spider folder\r
+shown in the directory tree on the left of the WinCVS display. Two things should happen. The Spider\r
+folder will be selected and the greyed-out arrow located just below the word Query in the top line will\r
+turn to solid green.\r
+\r
+For anyone using gcvs under Linux, the green arrow is located on the extreme left of the display,\r
+under the word File. A gcvs screen looks like:\r
+\r
+<htmlurl url="gcvs.jpg" name="gcvs.jpg">\r
+\r
+Click on the now green arrow to start the download process. An Update Settings box will be displayed\r
+to which you can simply say OK.\r
+\r
+<htmlurl url="update-OK.jpg" name="update-OK.jpg">\r
+\r
+For future reference, the Update Settings box is the place where you can enter information to revert\r
+to a prior version of DXSpider. Information on reverting to a Before Date is contained in the WinCVS\r
+manual.\r
+\r
+After a short period of time, a series of file names will scroll by in the lower pane of the WinCVS\r
+window. Eventually you should see\r
+<tscreen><verb>\r
+*****CVS exited normally with code 0*****\r
+\r
+</verb></tscreen>\r
+appear in the lower pane. You're done. The updated files are in place ready for you to stop and then\r
+restart your DXSpider. After the restart, you're running with the latest version of DXSpider.\r
+\r
+<htmlurl url="completed.jpg" name="completed.jpg">\r
+\r
+To paraphrase from the CVS section... Now the magic part! From now on when you want to update, simply\r
+connect to the Internet and start WinCVS.\r
+<tscreen><verb>\r
+Click on the greyed-out Spider directory in the left screen\r
+Click on the green down arrow\r
+Click OK on the Update Settings dialog box\r
+Restart your Spider software\r
+</verb></tscreen>\r
+\r
+<sect>The DXSpider command set\r
+\r
+<P>\r
+Below is a complete list of commands available from the cluster prompt.\r
+Most maintenance tasks are automatic but there are some commands that are useful\r
+for a sysop. These are listed below in alphabetical order. The number in\r
+brackets following the command name is the permissions level needed to use\r
+the command\r
+\r
+<sect1>accept/announce (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>accept/announce [0-9] <pattern></bf> Set an accept filter\r
+ line for announce\r
+</tt>\r
+\r
+<P>\r
+Create an 'accept this announce' line for a filter.\r
+\r
+An accept filter line means that if the announce matches this filter it is\r
+passed onto the user. See HELP FILTERS for more info. Please read this\r
+to understand how filters work - it will save a lot of grief later on.\r
+\r
+You can use any of the following things in this line:-\r
+\r
+<tscreen><verb>\r
+ info <string> eg: iota or qsl\r
+ by <prefixes> eg: G,M,2\r
+ origin <prefixes>\r
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ origin_itu <numbers>\r
+ origin_zone <numbers>\r
+ by_dxcc <numbers>\r
+ by_itu <numbers>\r
+ by_zone <numbers>\r
+ channel <prefixes>\r
+ wx 1 filter WX announces\r
+ dest <prefixes> eg: 6MUK,WDX (distros)\r
+</verb></tscreen>\r
+\r
+some examples:-\r
+\r
+<tscreen><verb>\r
+ acc/ann dest 6MUK\r
+ acc/ann 2 by_zone 14,15,16\r
+ (this could be all on one line: acc/ann dest 6MUK or by_zone 14,15,16)\r
+</verb></tscreen>\r
+\r
+or\r
+\r
+<tscreen><verb>\r
+ acc/ann by G,M,2 \r
+</verb></tscreen>\r
+\r
+This filter would only allow announces that were posted buy UK stations. \r
+You can use the tag 'all' to accept everything eg:\r
+\r
+<tscreen><verb>\r
+ acc/ann all\r
+</verb></tscreen>\r
+\r
+but this probably for advanced users...\r
+\r
+<sect1>accept/announce (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>accept/announce <call> [input] [0-9]<pattern></bf> Announce filter sysop version\r
+</tt>\r
+\r
+<P>\r
+This version allows a sysop to set a filter for a callsign as well as the\r
+default for nodes and users eg:-\r
+\r
+<tscreen><verb>\r
+ accept/ann by G,M,2\r
+ accept/ann input node_default by G,M,2\r
+ accept/ann user_default by G,M,2\r
+</verb></tscreen>\r
+\r
+<sect1>accept/route (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>accept/route <call> [0-9] <pattern></bf> Set an 'accept' filter line for routing\r
+</tt>\r
+\r
+<P>\r
+Create an 'accept this routing PC Protocol' line for a filter. \r
+\r
+<P>\r
+An accept filter line means that if a PC16/17/19/21/24/41/50 matches this filter\r
+it is passed thru that interface. See HELP FILTERING for more info. Please read this\r
+to understand how filters work - it will save a lot of grief later on.\r
+\r
+<P>\r
+You can use any of the following things in this line:-\r
+\r
+<tscreen><verb>\r
+ call <prefixes> the callsign of the thingy\r
+ call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ call_itu <numbers>\r
+ call_zone <numbers>\r
+ origin <prefixes> really the interface it came in on\r
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ origin_itu <numbers>\r
+ origin_zone <numbers>\r
+</verb></tscreen>\r
+\r
+<P>\r
+some examples:-\r
+\r
+<tscreen><verb>\r
+ acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)\r
+ acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)\r
+</verb></tscreen>\r
+\r
+<P>\r
+You can use the tag 'all' to accept everything eg:\r
+\r
+<tscreen><verb>\r
+ acc/route all\r
+</verb></tscreen>\r
+\r
+<sect1>accept/spots (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>accept/spots [0-9] <pattern></bf> Set an accept filter \r
+line for spots\r
+</tt>\r
+\r
+<P>\r
+Create an 'accept this spot' line for a filter.\r
+\r
+<P>\r
+An accept filter line means that if the spot matches this filter it is\r
+passed onto the user. See HELP FILTERS for more info. Please read this\r
+to understand how filters work - it will save a lot of grief later on.\r
+\r
+Please read the following section carefully. Though it looks similar,\r
+reformatting, corrections, and hopefully clarifications have been added.\r
+\r
+You can use any of the following things in this line:-\r
+\r
+<tscreen><verb>\r
+Filters for the station being spotted:\r
+ call <letters of the prefix, but NOT country inclusive>\r
+ call G --> G1AAA, GJ2BBB, GU3CCC, etc will be spotted\r
+ call K --> K1XX, K1XXX will be spotted\r
+ W1XX, W1XXX will NOT be spotted\r
+ call PA --> PA3EZL will be spotted\r
+ PB2FG will NOT be spotted\r
+\r
+ call_dxcc <numbers or prefixes>\r
+ call_dxcc G --> G1AAA will be spotted\r
+ GU1AAA will NOT be spotted (different country)\r
+ call_dxcc K --> K1XX, W1XX will be spotted (same country)\r
+ call_dxcc 139 --> PA3EZL and PB2FG will be spotted\r
+\r
+ call_itu <numbers>\r
+ call_zone <numbers>\r
+\r
+Filters for the callsign of the station doing the spotting:\r
+ by <letters of the prefix, but NOT country inclusive>\r
+ by G --> spots from G1AAA, GJ2BBB, GU3CCC, etc will be spotted\r
+ by K --> spots from K1XX, K1XXX will be spotted\r
+ spots from W1XX, W1XXX will NOT be spotted\r
+\r
+ by_dxcc <numbers or prefixes>\r
+ by_dxcc G --> spots from G1AAA will be spotted\r
+ spots from GU1AAA will NOT be spotted (different\r
+country)\r
+ by_dxcc K --> spots from K1XX, W1XX will be spotted (same country)\r
+ by_dxcc 139 --> spots from PA3EZL or PB2FG will be spotted\r
+\r
+ by_itu <numbers>\r
+ by_zone <numbers>\r
+\r
+Filters for the callsign of the "node" doing the spotting:\r
+ origin <letters of the prefix, but NOT country inclusive>\r
+ origin K --> spots from a node starting with K will be spotted\r
+ spots from a node starting with KK will NOT be spotted\r
+ spots from a node starting with W will NOT be spotted\r
+\r
+Filters for the callsign of the connected node or user (channel) doing the spotting:\r
+ channel <prefixes>\r
+ channel W1HR --> spots from the connected node W1HR will be spotted\r
+ channel K1QX --> spots from the connected user K1QX will be spotted\r
+\r
+ info <string> eg: iota or qsl\r
+ freq <range> eg: 0/30000 or hf or hf/cw or 6m,4m,2m\r
+ on <range> same as 'freq'\r
+\r
+</verb></tscreen>\r
+\r
+<P>\r
+For frequencies, you can use any of the band names defined in\r
+SHOW/BANDS and you can use a subband name like: cw, rtty, data, ssb -\r
+thus: hf/ssb. You can also just have a simple range like: 0/30000 -\r
+this is more efficient than saying simply: freq HF (but don't get\r
+too hung up about that)\r
+\r
+some examples:-\r
+\r
+<tscreen><verb>\r
+ acc/spot 1 on hf/cw\r
+ acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16)\r
+</verb></tscreen>\r
+\r
+You can use the tag 'all' to accept everything, eg:\r
+\r
+<tscreen><verb>\r
+ acc/spot 3 all\r
+</verb></tscreen>\r
+\r
+but this probably for advanced users...\r
+\r
+<sect1>accept/spots (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>accept/spots <call> [input] [0-9] <pattern></bf> Spot filter sysop version\r
+</tt>\r
+\r
+<P>\r
+This version allows a sysop to set a filter for a callsign as well as the\r
+default for nodes and users eg:-\r
+\r
+<tscreen><verb>\r
+ accept/spot db0sue-7 1 by_zone 14,15,16\r
+ accept/spot node_default all\r
+ set/hops node_default 10\r
+\r
+ accept/spot user_default by G,M,2\r
+</verb></tscreen>\r
+\r
+<sect1>accept/wcy (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>accept/wcy [0-9] <pattern></bf> set an accept WCY filter\r
+</tt>\r
+\r
+<P>\r
+It is unlikely that you will want to do this, but if you do then you can\r
+filter on the following fields:-\r
+\r
+<tscreen><verb>\r
+ by <prefixes> eg: G,M,2 \r
+ origin <prefixes>\r
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ origin_itu <numbers>\r
+ origin_zone <numbers>\r
+ by_dxcc <numbers>\r
+ by_itu <numbers>\r
+ by_zone <numbers>\r
+ channel <prefixes>\r
+</verb></tscreen>\r
+\r
+<P>\r
+There are no examples because WCY Broadcasts only come from one place and\r
+you either want them or not (see UNSET/WCY if you don't want them).\r
+\r
+This command is really provided for future use.\r
+\r
+See HELP FILTER for information.\r
+\r
+<sect1>accept/wcy (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>accept/wcy <call> [input] [0-9] <pattern></bf>\r
+WCY filter sysop version\r
+</tt>\r
+\r
+<P>\r
+This version allows a sysop to set a filter for a callsign as well as the\r
+default for nodes and users eg:-\r
+\r
+<tscreen><verb>\r
+ accept/wcy node_default all\r
+ set/hops node_default 10\r
+</verb></tscreen>\r
+\r
+<sect1>accept/wwv (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>accept/wwv [0-9] <pattern></bf> Set an accept WWV filter\r
+</tt>\r
+\r
+<P>\r
+It is unlikely that you will want to do this, but if you do then you can\r
+filter on the following fields:-\r
+\r
+<tscreen><verb>\r
+ by <prefixes> eg: G,M,2 \r
+ origin <prefixes>\r
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ origin_itu <numbers>\r
+ origin_zone <numbers>\r
+ by_dxcc <numbers>\r
+ by_itu <numbers>\r
+ by_zone <numbers>\r
+ channel <prefixes>\r
+</verb></tscreen>\r
+\r
+for example \r
+\r
+<tscreen><verb>\r
+ accept/wwv by_zone 4\r
+</verb></tscreen>\r
+\r
+is probably the only useful thing to do (which will only show WWV broadcasts\r
+by stations in the US).\r
+\r
+See HELP FILTER for information.\r
+\r
+<sect1>accept/wwv (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>accept/wwv <call> [input] [0-9] <pattern></bf>\r
+WWV filter sysop version\r
+</tt>\r
+\r
+<P>\r
+This version allows a sysop to set a filter for a callsign as well as the\r
+default for nodes and users eg:-\r
+\r
+<tscreen><verb>\r
+ accept/wwv db0sue-7 1 by_zone 4\r
+ accept/wwv node_default all\r
+ set/hops node_default 10\r
+\r
+ accept/wwv user_default by W,K\r
+</verb></tscreen>\r
+\r
+<sect1>announce (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>announce <text></bf> Send an announcement to local users\r
+</tt>\r
+\r
+<P>\r
+Send an announcement to LOCAL users only, where <text> is the text \r
+of the announcement you wish to broadcast. If you do not wish to receive\r
+announces, use the <em>set/noannounce</em> command. Any announces made by\r
+a sysop will override set/noannounce.\r
+\r
+<sect1>announce full (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>announce full <text></bf> Send an announcement cluster wide\r
+</tt>\r
+\r
+<P>\r
+This command will send your announcement across the whole cluster\r
+network.\r
+\r
+\r
+<sect1>announce sysop (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>announce sysop <text></bf>\r
+</tt>\r
+\r
+<P>\r
+Send an announcement to Sysops only\r
+\r
+<sect1>apropos (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>apropos <string></bf> Search the help database\r
+</tt>\r
+\r
+<P>\r
+Search the help database for <string> (it isn't case sensitive), \r
+and print the names of all the commands that may be relevant.\r
+\r
+<sect1>bye (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>bye</bf> Exit from the cluster\r
+</tt>\r
+\r
+<P>\r
+This will disconnect you from the cluster\r
+\r
+<sect1>catchup (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>catchup <node_call> All|[<msgno> ...]</bf> \r
+Mark a message as sent\r
+</tt>\r
+\r
+<P>\r
+When you send messages the fact that you have forwarded it to another node \r
+is remembered so that it isn't sent again. When you have a new partner\r
+node and you add their callsign to your /spider/msg/forward.pl file, all\r
+outstanding non-private messages will be forwarded to them. This may well\r
+be ALL the non-private messages. You can prevent this by using these \r
+commmands:-\r
+\r
+<tscreen><verb>\r
+ catchup GB7DJK all\r
+ catchup GB7DJK 300 301 302 303 500-510\r
+</verb></tscreen>\r
+ \r
+and to undo what you have just done:-\r
+ \r
+<tscreen><verb>\r
+ uncatchup GB7DJK all\r
+ uncatchup GB7DJK 300 301 302 303 500-510\r
+</verb></tscreen>\r
+\r
+which will arrange for them to be forward candidates again.\r
+\r
+Order is not important.\r
+\r
+<sect1>clear/announce (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>clear/announce [input] <callsign> [0-9|all]</bf> Clear an announce filter line\r
+</tt>\r
+\r
+<P>\r
+A sysop can clear an input or normal output filter for a user or the\r
+node_default or user_default. \r
+\r
+<sect1>clear/route (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>clear/route [input] ^lt;callsign> [0-9|all]</bf> Clear a route filter line\r
+</tt>\r
+\r
+<P>\r
+This command allows you to clear (remove) a line in a route filter or to \r
+remove the whole filter.\r
+\r
+see CLEAR/SPOTS for a more detailed explanation.\r
+\r
+A sysop can clear an input or normal output filter for a user or the\r
+node_default or user_default. \r
+\r
+<sect1>clear/spots (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>clear/spots [1|all]</bf> Clear a spot filter line\r
+</tt>\r
+\r
+<P>\r
+This command allows you to clear (remove) a line in a spot filter or to \r
+remove the whole filter.\r
+\r
+If you have a filter:-\r
+\r
+<tscreen><verb>\r
+ acc/spot 1 on hf/cw\r
+ acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16)\r
+</verb></tscreen>\r
+\r
+and you say:-\r
+\r
+<tscreen><verb>\r
+ clear/spot 1\r
+</verb></tscreen>\r
+\r
+you will be left with:-\r
+\r
+<tscreen><verb>\r
+ acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16)\r
+</verb></tscreen>\r
+\r
+If you do:\r
+\r
+<tscreen><verb>\r
+ clear/spot all\r
+</verb></tscreen>\r
+\r
+the filter will be completely removed.\r
+\r
+<sect1>clear/spots (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>clear/spots [input] <callsign> [0-9|all]</bf> Clear a spot filter line\r
+</tt>\r
+\r
+<P>\r
+A sysop can clear an input or normal output filter for a user or the\r
+node_default or user_default. \r
+\r
+<sect1>clear/wcy (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>clear/wcy [1|all]</bf> Clear a WCY filter line\r
+</tt>\r
+\r
+<P>\r
+This command allows you to clear (remove) a line in a WCY filter or to \r
+remove the whole filter.\r
+\r
+see CLEAR/SPOTS for a more detailed explanation.\r
+\r
+<sect1>clear/wcy (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>clear/wcy [input] <callsign> [0-9|all]</bf> Clear a WCY filter line\r
+</tt>\r
+\r
+<P>\r
+A sysop can clear an input or normal output filter for a user or the\r
+node_default or user_default. \r
+\r
+<sect1>clear/wwv (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>clear/wwv [1|all]</bf> Clear a WWV filter line\r
+</tt>\r
+\r
+<P>\r
+This command allows you to clear (remove) a line in a WWV filter or to\r
+remove the whole filter.\r
+\r
+see CLEAR/SPOTS for a more detailed explanation.\r
+\r
+<sect1>clear/wwv (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>clear/wwv [input] <callsign> [0-9|all]</bf> Clear a WWV filter line\r
+</tt>\r
+\r
+<P>\r
+A sysop can clear an input or normal output filter for a user or the\r
+node_default or user_default.\r
+\r
+<sect1>connect (5) \r
+\r
+<P>\r
+<tt>\r
+<bf>connect <callsign></bf> Start a connection to another DX Cluster\r
+</tt>\r
+\r
+<P>\r
+Start a connection process that will culminate in a new connection to the\r
+DX cluster <callsign>. This process creates a new 'client' process which will\r
+use the script in /spider/connect/<callsign> to effect the 'chat' exchange\r
+necessary to traverse the network(s) to logon to the cluster <callsign>.\r
+\r
+<sect1>dbavail (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>dbavail</bf> Show a list of all the databases in the system\r
+</tt>\r
+\r
+<P>\r
+The title says it all really, this command lists all the databases defined\r
+in the system. It is also aliased to SHOW/COMMAND.\r
+\r
+<sect1>dbcreate (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>dbcreate <name></bf> Create a database entry<newline>\r
+<bf>dbcreate <name> chain <name> [<name>..]</bf> Create a \r
+chained database entry<newline>\r
+<bf>dbcreate <name> remote <node></bf> Create a remote database\r
+entry<newline>\r
+</tt>\r
+\r
+<P>\r
+DBCREATE allows you to define a database in the system. It doesn't actually\r
+create anything, just defines it.\r
+\r
+The databases that are created are simple DB_File hash databases, they are \r
+therefore already 'indexed'.\r
+\r
+You can define a local database with the first form of the command eg:\r
+\r
+ DBCREATE oblast\r
+\r
+You can also chain databases with the addition of the 'chain' keyword. \r
+This will search each database one after the other. A typical example \r
+is:\r
+\r
+ DBCREATE sdx_qsl chain sql_ad\r
+\r
+No checking is done to see if the any of the chained databases exist, in\r
+fact it is usually better to do the above statement first then do each of\r
+the chained databases.\r
+\r
+Databases can exist offsite. To define a database that lives on another \r
+node do:\r
+\r
+ DBCREATE buckmaster remote gb7dxc\r
+\r
+Remote databases cannot be chained; however, the last database in a \r
+a chain can be a remote database eg:\r
+\r
+ DBCREATE qsl chain gb7dxc\r
+\r
+To see what databases have been defined do:\r
+\r
+ DBAVAIL (or it will have been aliased to SHOW/COMMAND)\r
+\r
+It would be normal for you to add an entry into your local Aliases file\r
+to allow people to use the 'SHOW/<dbname>' style syntax. So you would\r
+need to add a line like:-\r
+\r
+<tscreen><verb>\r
+ 's' => [\r
+ ..\r
+ ..\r
+ '^sh\w*/buc', 'dbshow buckmaster', 'dbshow',\r
+ ..\r
+ ..\r
+ ],\r
+</verb></tscreen>\r
+\r
+to allow \r
+\r
+ SH/BUCK g1tlh\r
+\r
+to work as they may be used to.\r
+\r
+See DBIMPORT for the importing of existing AK1A format data to databases.\r
+See DBSHOW for generic database enquiry\r
+\r
+<sect1>dbimport (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>dbimport <dbname></bf> Import AK1A data into a database\r
+</tt>\r
+\r
+<P>\r
+If you want to import or update data in bulk to a database you can use\r
+this command. It will either create or update entries into an existing\r
+database. For example:-\r
+\r
+ DBIMPORT oblast /tmp/OBLAST.FUL\r
+\r
+will import the standard OBLAST database that comes with AK1A into the\r
+oblast database held locally.\r
+\r
+<sect1>dbremove (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>dbremove <dbname></bf> Delete a database\r
+</tt>\r
+\r
+<P>\r
+DBREMOVE will completely remove a database entry and also delete any data\r
+file that is associated with it. \r
+\r
+There is no warning, no comeback, no safety net. \r
+\r
+For example:\r
+\r
+ DBREMOVE oblast \r
+\r
+will remove the oblast database from the system and it will also remove\r
+the associated datafile.\r
+\r
+I repeat:\r
+\r
+There is no warning, no comeback, no safety net.\r
+\r
+You have been warned.\r
+\r
+<sect1>dbshow (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>dbshow <dbname> <key></bf> Display an entry, if it exists, \r
+in a database\r
+</tt>\r
+\r
+<P>\r
+This is the generic user interface to the database to the database system.\r
+It is expected that the sysop will add an entry to the local Aliases file\r
+so that users can use the more familiar AK1A style of enquiry such as:\r
+\r
+<tscreen><verb>\r
+ SH/BUCK G1TLH\r
+</verb></tscreen>\r
+\r
+but if he hasn't and the database really does exist (use DBAVAIL or\r
+SHOW/COMMAND to find out) you can do the same thing with:\r
+\r
+<tscreen><verb>\r
+ DBSHOW buck G1TLH\r
+</verb></tscreen>\r
+\r
+\r
+<sect1>debug (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>debug</bf> Set the cluster program into debug mode\r
+</tt>\r
+\r
+<P>\r
+Executing this command will only have an effect if you are running the cluster\r
+in debug mode i.e.\r
+\r
+<tscreen><verb>\r
+ perl -d cluster.pl\r
+</verb></tscreen>\r
+\r
+It will interrupt the cluster just after the debug command has finished.\r
+\r
+<sect1>delete/user (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>delete/user <callsign></bf> Delete a user from the User Database\r
+</tt>\r
+\r
+<P>\r
+This command will completely remove a one or more users from the database.\r
+\r
+There is NO SECOND CHANCE.\r
+\r
+It goes without saying that you should use this command CAREFULLY!\r
+\r
+<sect1>demonstrate (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>demonstrate <call> <command></bf> Demonstrate a command to another user\r
+</tt>\r
+\r
+<P>\r
+This command is provided so that sysops can demonstrate commands to \r
+other users. It runs a command as though that user had typed it in and\r
+then sends the output to that user, together with the command that \r
+caused it.\r
+\r
+<tscreen><verb>\r
+ DEMO g7brn sh/dx iota oc209\r
+ DEMO g1tlh set/here\r
+</verb></tscreen>\r
+\r
+Note that this command is similar to SPOOF and will have the same side\r
+effects. Commands are run at the privilege of the user which is being\r
+demonstrated to.\r
+\r
+<sect1>directory (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>directory</bf> List messages<newline> \r
+<bf>directory all</bf> List all messages<newline>\r
+<bf>directory own</bf> List your own messages<newline>\r
+<bf>directory new</bf> List all new messages<newline>\r
+<bf>directory to <call></bf> List all messages to <call><newline>\r
+<bf>directory from <call></bf> List all messages from <call><newline>\r
+<bf>directory subject <string></bf> List all messages with <string> \r
+in subject<newline>\r
+<bf>directory <nn></bf> List last <nn> messages<newline>\r
+<bf>directory <from>-<to></bf> List messages <from> message <to> message <newline>\r
+</tt>\r
+\r
+<P>\r
+List the messages in the messages directory.\r
+\r
+If there is a 'p' one space after the message number then it is a \r
+personal message. If there is a '-' between the message number and the\r
+'p' then this indicates that the message has been read.\r
+\r
+You can use shell escape characters such as '*' and '?' in the <call>\r
+fields.\r
+\r
+You can combine some of the various directory commands together eg:-\r
+\r
+<tscreen><verb>\r
+ DIR TO G1TLH 5\r
+or \r
+ DIR SUBJECT IOTA 200-250\r
+</verb></tscreen>\r
+\r
+You can abbreviate all the commands to one letter and use ak1a syntax:-\r
+\r
+<tscreen><verb>\r
+ DIR/T G1* 10\r
+ DIR/S QSL 10-100 5\r
+</verb></tscreen>\r
+\r
+\r
+<sect1>directory (extended for sysops) (5)\r
+\r
+<P>\r
+Works just like the user command except that sysops can see ALL messages.\r
+\r
+<sect1>disconnect (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>disconnect <call> [<call> ...]</bf> Disconnect a user or node\r
+</tt>\r
+\r
+<P>\r
+Disconnect any <call> connected locally\r
+\r
+<sect1>dx (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>dx [by <call>] <freq> <call> <remarks></bf> Send a DX spot\r
+</tt>\r
+\r
+<P>\r
+This is how you send a DX Spot to other users. You can, in fact, now\r
+enter the <freq> and the <call> either way round. \r
+\r
+<tscreen><verb>\r
+ DX FR0G 144.600\r
+ DX 144.600 FR0G\r
+ DX 144600 FR0G \r
+</verb></tscreen>\r
+\r
+will all give the same result. You can add some remarks to the end\r
+of the command and they will be added to the spot.\r
+\r
+<tscreen><verb>\r
+ DX FR0G 144600 this is a test\r
+</verb></tscreen>\r
+\r
+You can credit someone else by saying:-\r
+\r
+<tscreen><verb>\r
+ DX by G1TLH FR0G 144.600 he isn't on the cluster\r
+</verb></tscreen>\r
+\r
+The <freq> is compared against the available bands set up in the \r
+cluster. See SHOW/BANDS for more information.\r
+\r
+<sect1>export (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>export <msgno> <filename></bf> Export a message to a file\r
+</tt>\r
+\r
+<P>\r
+Export a message to a file. This command can only be executed on a local\r
+console with a fully privileged user. The file produced will be in a form\r
+ready to be imported back into the cluster by placing it in the import \r
+directory (/spider/msg/import).\r
+\r
+This command cannot overwrite an existing file. This is to provide some \r
+measure of security. Any files written will owned by the same user as the \r
+main cluster, otherwise you can put the new files anywhere the cluster can\r
+access. For example:-\r
+\r
+ EXPORT 2345 /tmp/a\r
+\r
+<sect1>export_users (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>export_users [<filename>]</bf> Export the users database to ascii\r
+</tt>\r
+\r
+<P>\r
+Export the users database to a file in ascii format. If no filename\r
+is given then it will export the file to /spider/data/user_asc.\r
+\r
+If the file already exists it will be renamed to <filename>.o. In fact\r
+up to 5 generations of the file can be kept each one with an extra 'o' on the\r
+suffix. \r
+\r
+BE WARNED: this will write to any file you have write access to. No check is\r
+made on the filename (if any) that you specify.\r
+\r
+<sect1>filtering (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>filtering</bf> Filtering things in DXSpider\r
+</tt>\r
+\r
+<P>\r
+There are a number of things you can filter in the DXSpider system. They\r
+all use the same general mechanism.\r
+\r
+In general terms you can create a 'reject' or an 'accept' filter which\r
+can have up to 10 lines in it. You do this using, for example:-\r
+ \r
+ accept/spots .....\r
+ reject/spots .....\r
+\r
+where ..... are the specific commands for that type of filter. There\r
+are filters for spots, wwv, announce, wcy and (for sysops)\r
+connects. See each different accept or reject command reference for\r
+more details.\r
+\r
+There is also a command to clear out one or more lines in a filter and\r
+one to show you what you have set. They are:-\r
+\r
+ clear/spots 1\r
+ clear/spots all\r
+\r
+and \r
+ \r
+ show/filter\r
+\r
+There is clear/xxxx command for each type of filter.\r
+\r
+For now we are going to use spots for the examples, but you can apply\r
+the principles to all types of filter.\r
+\r
+There are two main types of filter 'accept' or 'reject'; which you use\r
+depends entirely on how you look at the world and what is least\r
+writing to achieve what you want. Each filter has 10 lines (of any\r
+length) which are tried in order. If a line matches then the action\r
+you have specified is taken (ie reject means ignore it and accept\r
+means gimme it).\r
+\r
+The important thing to remember is that if you specify a 'reject'\r
+filter (all the lines in it say 'reject/spots' (for instance) then if\r
+a spot comes in that doesn't match any of the lines then you will get\r
+it BUT if you specify an 'accept' filter then any spots that don't\r
+match are dumped. For example if I have a one line accept filter:-\r
+\r
+ accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)\r
+\r
+then automatically you will ONLY get VHF spots from or to CQ zones 14\r
+15 and 16. If you set a reject filter like:\r
+\r
+ reject/spots on hf/cw\r
+\r
+Then you will get everything EXCEPT HF CW spots, If you am interested in IOTA\r
+and will work it even on CW then you could say:-\r
+\r
+ reject/spots on hf/cw and not info iota\r
+\r
+But in that case you might only be interested in iota and say:-\r
+\r
+ accept/spots not on hf/cw or info iota\r
+\r
+which is exactly the same. You should choose one or the other until\r
+you are confortable with the way it works. Yes, you can mix them\r
+(actually you can have an accept AND a reject on the same line) but\r
+don't try this at home until you can analyse the results that you get\r
+without ringing up the sysop for help.\r
+\r
+You can arrange your filter lines into logical units, either for your\r
+own understanding or simply convenience. I have one set frequently:-\r
+\r
+ reject/spots 1 on hf/cw\r
+ reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16) \r
+\r
+What this does is to ignore all HF CW spots (being a class B I can't\r
+read any CW and couldn't possibly be interested in HF :-) and also\r
+rejects any spots on VHF which don't either originate or spot someone\r
+in Europe.\r
+\r
+This is an exmaple where you would use the line number (1 and 2 in\r
+this case), if you leave the digit out, the system assumes '1'. Digits\r
+'0'-'9' are available.\r
+\r
+You can leave the word 'and' out if you want, it is implied. You can\r
+use any number of brackets to make the 'expression' as you want\r
+it. There are things called precedence rules working here which mean\r
+that you will NEED brackets in a situation like line 2 because,\r
+without it, will assume:-\r
+\r
+ (on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16 \r
+\r
+annoying, but that is the way it is. If you use OR - use\r
+brackets. Whilst we are here CASE is not important. 'And BY_Zone' is\r
+just 'and by_zone'.\r
+\r
+If you want to alter your filter you can just redefine one or more\r
+lines of it or clear out one line. For example:-\r
+\r
+ reject/spots 1 on hf/ssb\r
+\r
+or \r
+\r
+ clear/spots 1\r
+\r
+To remove the filter in its entirty:-\r
+\r
+ clear/spots all\r
+\r
+There are similar CLEAR commands for the other filters:-\r
+\r
+ clear/announce\r
+ clear/wcy\r
+ clear/wwv\r
+\r
+ADVANCED USERS:-\r
+\r
+Once you are happy with the results you get, you may like to experiment. \r
+\r
+my example that filters hf/cw spots and accepts vhf/uhf spots from EU\r
+can be written with a mixed filter, eg:\r
+\r
+ rej/spot on hf/cw\r
+ acc/spot on 0/30000\r
+ acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)\r
+\r
+each filter slot actually has a 'reject' slot and an 'accept'\r
+slot. The reject slot is executed BEFORE the accept slot.\r
+\r
+It was mentioned earlier that after a reject test that doesn't match,\r
+the default for following tests is 'accept', the reverse is true for\r
+'accept'. In the example what happens is that the reject is executed\r
+first, any non hf/cw spot is passed to the accept line, which lets\r
+thru everything else on HF.\r
+\r
+The next filter line lets through just VHF/UHF spots from EU.\r
+\r
+<sect1>forward/latlong (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>forward/latlong <node_call></bf> Send latitude and longitude \r
+information to another cluster\r
+</tt>\r
+\r
+<P>\r
+This command sends all the latitude and longitude information that your\r
+cluster is holding against callsigns. One advantage of recieving this\r
+information is that more locator information is held by you. This\r
+means that more locators are given on the DX line assuming you have\r
+<em>set/dxgrid</em> enabled. This could be a LOT of information though, so\r
+it is not recommended on slow links.\r
+\r
+<sect1>forward/opername (1)\r
+\r
+<P>\r
+<tt>\r
+<bf>forward/opername <call></bf> Send out information on this <call> \r
+to all clusters\r
+</tt>\r
+\r
+<P>\r
+This command sends out any information held in the user file which can \r
+be broadcast in PC41 protocol packets. This information is Name, QTH, Location\r
+and Homenode. PC41s are only sent for the information that is available.\r
+\r
+<sect1>help (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>help <cmd></bf> Get help on a command\r
+</tt>\r
+\r
+<P>\r
+All commands can be abbreviated, so SHOW/DX can be abbreviated\r
+to SH/DX, ANNOUNCE can be shortened to AN and so on.\r
+\r
+Look at the APROPOS <string> command which will search the help database\r
+for the <string> you specify and give you a list of likely commands\r
+to look at with HELP.\r
+\r
+<sect1>init (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>init <node call></bf> Re-initialise a link to an AK1A compatible node\r
+</tt>\r
+\r
+<P>\r
+This command attempts to re-initialise a link to a (usually) AK1A node\r
+that has got confused, usually by a protocol loop of some kind. It may\r
+work - but you usually will be better off simply disconnecting it (or\r
+better, if it is a real AK1A node, doing an RCMD <node> DISC/F <your\r
+node>).\r
+\r
+Best of luck - you will need it.\r
+\r
+<sect1>kill (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>kill <msgno> [<msgno> ..]</bf> Delete a message \r
+from the local system\r
+</tt>\r
+\r
+<P>\r
+Delete a message from the local system. You will only be able to\r
+delete messages that you have originated or been sent (unless you are\r
+the sysop).\r
+\r
+<sect1>kill (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>kill <msgno> [<msgno> ...]</bf> Remove or erase a message from \r
+the system<newline>\r
+<bf>kill from <call></bf> Remove all messages from a callsign<newline>\r
+<bf>kill to <call></bf> Remove all messages to a callsign<newline>\r
+</tt>\r
+\r
+<P>\r
+You can get rid of any message to or originating from your callsign using \r
+this command. You can remove more than one message at a time.\r
+\r
+As a sysop you can kill any message on the system.\r
+\r
+<sect1>kill full (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>kill full <msgno> [<msgno>]</bf> Delete a message from the \r
+whole cluster\r
+</tt>\r
+\r
+<P>\r
+Delete a message (usually a 'bulletin') from the whole cluster system. \r
+\r
+This uses the subject field, so any messages that have exactly the same subject\r
+will be deleted. Beware!\r
+\r
+<sect1>kill/expunge (6)\r
+\r
+<P>\r
+<tt>\r
+<bf>kill/expunge <msgno> [<msgno>..]</bf>Expunge a message\r
+</tt>\r
+\r
+<P>\r
+Deleting a message using the normal KILL commands only marks that message\r
+for deletion. The actual deletion only happens later (usually two days later).\r
+\r
+The KILL EXPUNGE command causes the message to be truly deleted more or less\r
+immediately.\r
+\r
+It otherwise is used in the same way as the KILL command.\r
+\r
+\r
+<sect1>links (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>links</bf> Show which nodes are physically connected\r
+</tt>\r
+\r
+<P>\r
+This is a quick listing that shows which links are connected and\r
+some information about them. See WHO for a list of all connections.\r
+\r
+\r
+<sect1>load/aliases (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>load/aliases</bf> Reload the command alias table\r
+</tt>\r
+\r
+<P>\r
+Reload the /spider/cmd/Aliases file after you have editted it. You will need to\r
+do this if you change this file whilst the cluster is running in order for the\r
+changes to take effect.\r
+\r
+<sect1>load/badmsg (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>load/badmsg</bf> Reload the bad message table\r
+</tt>\r
+\r
+<P>\r
+Reload the /spider/msg/badmsg.pl file if you have changed it manually whilst\r
+the cluster is running. This table contains a number of perl regular \r
+expressions which are searched for in the fields targetted of each message. \r
+If any of them match then that message is immediately deleted on receipt. \r
+\r
+<sect1>load/badwords (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>load/badwords</bf> Reload the bad words table\r
+</tt>\r
+\r
+<P>\r
+Reload the /spider/data/badwords file if you have changed it manually whilst\r
+the cluster is running. This file contains a list of words which, if found\r
+on certain text portions of PC protocol, will cause those protocol frames\r
+to be rejected. It will all put out a message if any of these words are\r
+used on the announce, dx and talk commands. The words can be one or \r
+more on a line, lines starting with '#' are ignored.\r
+\r
+<sect1>load/bands (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>load/bands</bf> Reload the band limits table\r
+</tt>\r
+\r
+<P>\r
+Reload the /spider/data/bands.pl file if you have changed it manually whilst\r
+the cluster is running. \r
+\r
+<sect1>load/cmd_cache (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>load/cmd_cache</bf> Reload the automatic command cache\r
+</tt>\r
+\r
+<P>\r
+Normally, if you change a command file in the cmd or local_cmd tree it will\r
+automatially be picked up by the cluster program. Sometimes it can get confused\r
+if you are doing a lot of moving commands about or delete a command in the \r
+local_cmd tree and want to use the normal one again. Execute this command to\r
+reset everything back to the state it was just after a cluster restart.\r
+\r
+<sect1>load/forward (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>load/forward</bf> Reload the msg forwarding routing table\r
+</tt>\r
+\r
+Reload the /spider/msg/forward.pl file if you have changed it\r
+manually whilst the cluster is running.\r
+\r
+<sect1>load/messages (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>load/messages</bf> Reload the system messages file\r
+</tt>\r
+\r
+<P>\r
+If you change the /spider/perl/Messages file (usually whilst fiddling/writing ne\r
+commands) you can have them take effect during a cluster session by executing this\r
+command. You need to do this if get something like :-\r
+\r
+unknown message 'xxxx' in lang 'en'\r
+\r
+<sect1>load/prefixes (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>load/prefixes</bf> Reload the prefix table\r
+</tt>\r
+\r
+<P>\r
+Reload the /spider/data/prefix_data.pl file if you have changed it manually \r
+whilst the cluster is running. \r
+\r
+<sect1>merge (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>merge <node> [<no spots>/<no wwv>]</bf> Ask for the \r
+latest spots and WWV\r
+</tt>\r
+\r
+<P>\r
+MERGE allows you to bring your spot and wwv database up to date. By default\r
+it will request the last 10 spots and 5 WWVs from the node you select. The \r
+node must be connected locally.\r
+\r
+You can request any number of spots or wwv and although they will be appended\r
+to your databases they will not duplicate any that have recently been added \r
+(the last 2 days for spots and last month for WWV data).\r
+\r
+<sect1>msg (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>msg <cmd> <msgno> [data ...]</bf> Alter various message \r
+parameters\r
+</tt>\r
+\r
+<P>\r
+Alter message parameters like To, From, Subject, whether private or bulletin\r
+or return receipt (RR) is required or whether to keep this message from timing\r
+out.\r
+\r
+<tscreen><verb>\r
+ MSG TO <msgno> <call> - change TO callsign to <call>\r
+ MSG FRom <msgno> <call> - change FROM callsign to <call>\r
+ MSG PRrivate <msgno> - set private flag\r
+ MSG NOPRrivate <msgno> - unset private flag\r
+ MSG RR <msgno> - set RR flag\r
+ MSG NORR <msgno> - unset RR flag\r
+ MSG KEep <msgno> - set the keep flag (message won't be deleted ever)\r
+ MSG NOKEep <msgno> - unset the keep flag\r
+ MSG SUbject <msgno> <new> - change the subject to <new>\r
+ MSG WAittime <msgno> - remove any waitting time for this message\r
+ MSG NOREad <msgno> - mark message as unread\r
+ MSG REad <msgno> - mark message as read\r
+ MSG QUeue - queue any outstanding bulletins\r
+ MSG QUeue 1 - queue any outstanding private messages\r
+</verb></tscreen>\r
+\r
+You can look at the status of a message by using:-\r
+\r
+ STAT/MSG <msgno> \r
+\r
+This will display more information on the message than DIR does.\r
+\r
+<sect1>pc (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>pc <call> <text></bf> Send text (eg PC Protocol) to <call>\r
+</tt>\r
+\r
+<P>\r
+Send some arbitrary text to a locally connected callsign. No processing is done on\r
+the text. This command allows you to send PC Protocol to unstick things if problems\r
+arise (messages get stuck etc). eg:-\r
+\r
+ pc gb7djk PC33^GB7TLH^GB7DJK^400^\r
+\r
+You can also use in the same way as a talk command to a connected user but\r
+without any processing, added of "from <blah> to <blah>" or whatever.\r
+\r
+ pc G1TLH Try doing that properly!!!\r
+\r
+<sect1>ping (1)\r
+\r
+<P>\r
+<tt>\r
+<bf>ping <node></bf> Check the link quality between nodes\r
+</tt>\r
+\r
+<P>\r
+his command allows you to send a frame to another cluster node on\r
+the network and get a return frame. The time it takes to do this\r
+is a good indication of the quality of the link. The actual time\r
+it takes is output to the console in seconds.\r
+Any visible cluster node can be PINGed.\r
+\r
+\r
+<sect1>rcmd (1)\r
+\r
+<P>\r
+<tt>\r
+<bf>rcmd <node call> <cmd></bf> Send a command to another DX cluster\r
+</tt>\r
+\r
+<P>\r
+This command allows you to send nearly any command to another DX Cluster\r
+node that is connected to the system. \r
+\r
+Whether you get any output is dependant on a) whether the other system knows\r
+that the node callsign of this cluster is in fact a node b) whether the\r
+other system is allowing RCMDs from this node and c) whether you have\r
+permission to send this command at all.\r
+\r
+<sect1>read (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>read</bf> Read the next unread personal message addressed to you<newline>\r
+<bf>read <msgno></bf> Read the specified message<newline>\r
+</tt>\r
+\r
+<P>\r
+You can read any messages that are sent as 'non-personal' and also any\r
+message either sent by or sent to your callsign.\r
+\r
+\r
+<sect1>read (extended for sysops) (5) \r
+\r
+<P>\r
+<tt>\r
+<bf>read <msgno></bf> Read a message on the system\r
+</tt>\r
+\r
+<P>\r
+As a sysop you may read any message on the system\r
+\r
+<sect1>reject/announce\r
+\r
+<P>\r
+<tt>\r
+<bf>reject/announce [0-9] <pattern></bf> Set a reject filter\r
+for announce\r
+</tt>\r
+\r
+<P>\r
+Create an 'reject this announce' line for a filter. \r
+\r
+An reject filter line means that if the announce matches this filter it is\r
+passed onto the user. See HELP FILTERS for more info. Please read this\r
+to understand how filters work - it will save a lot of grief later on.\r
+\r
+You can use any of the following things in this line:-\r
+\r
+<tscreen><verb>\r
+ info <string> eg: iota or qsl\r
+ by <prefixes> eg: G,M,2 \r
+ origin <prefixes>\r
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ origin_itu <numbers>\r
+ origin_zone <numbers>\r
+ by_dxcc <numbers>\r
+ by_itu <numbers>\r
+ by_zone <numbers>\r
+ channel <prefixes>\r
+ wx 1 filter WX announces\r
+ dest <prefixes> eg: 6MUK,WDX (distros)\r
+</verb></tscreen>\r
+\r
+some examples:-\r
+\r
+<tscreen><verb>\r
+ rej/ann by_zone 14,15,16 and not by G,M,2\r
+</verb></tscreen>\r
+ \r
+You can use the tag 'all' to reject everything eg:\r
+\r
+<tscreen><verb>\r
+ rej/ann all\r
+</verb></tscreen>\r
+\r
+but this probably for advanced users...\r
+\r
+<sect1>reject/announce (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>reject/announce <call> [input] [0-9] <pattern></bf> Announce filter sysop version\r
+</tt>\r
+\r
+<P>\r
+This version allows a sysop to set a filter for a callsign as well as the\r
+default for nodes and users eg:-\r
+\r
+<tscreen><verb>\r
+ reject/ann by G,M,2\r
+ reject/ann input node_default by G,M,2\r
+ reject/ann user_default by G,M,2\r
+</verb></tscreen>\r
+\r
+<sect1>reject/route (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>reject/route <call> [0-9] <pattern></bf> Set an 'reject' filter line for routing\r
+</tt>\r
+\r
+<P>\r
+Create an 'reject this routing PC Protocol' line for a filter. \r
+\r
+<P>\r
+An reject filter line means that if a PC16/17/19/21/24/41/50 matches this filter \r
+it is NOT passed thru that interface. See HELP FILTERING for more info. Please \r
+read this to understand how filters work - it will save a lot of grief later on.\r
+You can use any of the following things in this line:-\r
+\r
+<tscreen><verb>\r
+ call <prefixes> the callsign of the thingy\r
+ call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ call_itu <numbers>\r
+ call_zone <numbers>\r
+ origin <prefixes> really the interface it came in on\r
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ origin_itu <numbers>\r
+ origin_zone <numbers>\r
+</verb></tscreen>\r
+\r
+<P>\r
+some examples:-\r
+\r
+<tscreen><verb>\r
+ rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes)\r
+</verb></tscreen>\r
+\r
+<P>\r
+You can use the tag 'all' to reject everything eg:\r
+\r
+<tscreen><verb>\r
+ rej/route all (equiv to [very] restricted mode)\r
+</verb></tscreen>\r
+\r
+<sect1>reject/spots (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>reject/spots [0-9] <pattern></bf> Set a reject filter \r
+line for spots\r
+</tt>\r
+\r
+<P>\r
+Create a 'reject this spot' line for a filter. \r
+\r
+A reject filter line means that if the spot matches this filter it is\r
+dumped (not passed on). See HELP FILTERS for more info. Please read this\r
+to understand how filters work - it will save a lot of grief later on.\r
+\r
+You can use any of the following things in this line:-\r
+\r
+<tscreen><verb>\r
+ freq <range> eg: 0/30000 or hf or hf/cw or 6m,4m,2m\r
+ on <range> same as 'freq'\r
+ call <prefixes> eg: G,PA,HB9\r
+ info <string> eg: iota or qsl\r
+ by <prefixes> \r
+ call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ call_itu <numbers>\r
+ call_zone <numbers>\r
+ by_dxcc <numbers>\r
+ by_itu <numbers>\r
+ by_zone <numbers>\r
+ origin <prefixes>\r
+ channel <prefixes>\r
+</verb></tscreen>\r
+\r
+For frequencies, you can use any of the band names defined in\r
+SHOW/BANDS and you can use a subband name like: cw, rtty, data, ssb -\r
+thus: hf/ssb. You can also just have a simple range like: 0/30000 -\r
+this is more efficient than saying simply: on HF (but don't get\r
+too hung up about that)\r
+\r
+some examples:-\r
+\r
+<tscreen><verb>\r
+ rej/spot 1 on hf\r
+ rej/spot 2 on vhf and not (by_zone 14,15,16 or call_zone 14,15,16)\r
+</verb></tscreen>\r
+\r
+You can use the tag 'all' to reject everything eg:\r
+\r
+<tscreen><verb>\r
+ rej/spot 3 all\r
+</verb></tscreen>\r
+\r
+but this probably for advanced users...\r
+\r
+<sect1>reject/spots (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>reject/spots <call> [input] [0-9] <pattern></bf>\r
+ Reject spot filter sysop version \r
+</tt>\r
+\r
+<P>\r
+This version allows a sysop to set a filter for a callsign as well as the\r
+default for nodes and users eg:-\r
+\r
+<tscreen><verb>\r
+ reject/spot db0sue-7 1 by_zone 14,15,16\r
+ reject/spot node_default all\r
+ set/hops node_default 10\r
+\r
+ reject/spot user_default by G,M,2\r
+</verb></tscreen>\r
+\r
+<sect1>reject/wcy (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>reject/wcy [0-9] <pattern></bf> Set a reject WCY filter\r
+</tt>\r
+\r
+<P>\r
+It is unlikely that you will want to do this, but if you do then you can\r
+filter on the following fields:-\r
+\r
+<tscreen><verb>\r
+ by <prefixes> eg: G,M,2 \r
+ origin <prefixes>\r
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ origin_itu <numbers>\r
+ origin_zone <numbers>\r
+ by_dxcc <numbers>\r
+ by_itu <numbers>\r
+ by_zone <numbers>\r
+ channel <prefixes>\r
+</verb></tscreen>\r
+\r
+There are no examples because WCY Broadcasts only come from one place and\r
+you either want them or not (see UNSET/WCY if you don't want them).\r
+\r
+This command is really provided for future use.\r
+\r
+See HELP FILTER for information.\r
+\r
+<sect1>reject/wcy (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>reject/wcy <call> [input] [0-9] <pattern></bf>\r
+ WCY reject filter sysop version\r
+</tt>\r
+\r
+<P>\r
+This version allows a sysop to set a filter for a callsign as well as the\r
+default for nodes and users eg:-\r
+\r
+ reject/wcy gb7djk all\r
+\r
+<sect1>reject/wwv (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>reject/wwv [0-9] <pattern></bf> Set a reject WWV filter\r
+</tt>\r
+\r
+<P>\r
+It is unlikely that you will want to do this, but if you do then you can\r
+filter on the following fields:-\r
+\r
+<tscreen><verb>\r
+ by <prefixes> eg: G,M,2 \r
+ origin <prefixes>\r
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)\r
+ origin_itu <numbers>\r
+ origin_zone <numbers>\r
+ by_dxcc <numbers>\r
+ by_itu <numbers>\r
+ by_zone <numbers>\r
+ channel <prefixes>\r
+</verb></tscreen>\r
+\r
+for example \r
+\r
+<tscreen><verb>\r
+ reject/wwv by_zone 14,15,16\r
+</verb></tscreen>\r
+\r
+is probably the only useful thing to do (which will only show WWV broadcasts\r
+by stations in the US).\r
+\r
+See HELP FILTER for information.\r
+\r
+<sect1>reject/wwv (extended for sysops) (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>reject/wwv <call> [input] [0-9] <pattern></bf>\r
+ WWV reject filter sysop version\r
+</tt>\r
+\r
+<P>This version allows a sysop to set a filter for a callsign as well as the\r
+default for nodes and users eg:-\r
+\r
+<tscreen><verb>\r
+ reject/wwv db0sue-7 1 by_zone 4\r
+ reject/wwv node_default all\r
+\r
+ reject/wwv user_default by W\r
+</verb></tscreen>\r
+\r
+<sect1>reply (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>reply</bf> Reply (privately) to the last message that you have read<newline>\r
+<bf>reply <msgno></bf> Reply (privately) to the specified message<newline>\r
+<bf>reply B <msgno></bf> Reply as a Bulletin to the specified message<newline>\r
+<bf>reply NOPrivate <msgno></bf> Reply as a Bulletin to the specified\r
+message<newline>\r
+<bf>reply RR <msgno></bf> Reply to the specified message with read \r
+receipt<newline>\r
+</tt>\r
+\r
+<P>\r
+You can reply to a message and the subject will automatically have\r
+"Re:" inserted in front of it, if it isn't already present.\r
+\r
+You can also use all the extra qualifiers such as RR, PRIVATE, \r
+NOPRIVATE, B that you can use with the SEND command (see SEND\r
+for further details)\r
+\r
+<sect1>send (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>send <call> [<call> ...]</bf> Send a message to \r
+one or more callsigns<newline>\r
+<bf>send RR <call></bf> Send a message and ask for a read receipt<newline>\r
+<bf>send COPY <msgno> <call></bf> Send a copy of a message \r
+to someone<newline>\r
+<bf>send PRIVATE <call></bf> Send a personal message<newline>\r
+<bf>send NOPRIVATE <call></bf> Send a message to all stations<newline>\r
+</tt>\r
+\r
+<P>\r
+All the SEND commands will create a message which will be sent either to\r
+an individual callsign or to one of the 'bulletin' addresses. \r
+\r
+SEND <call> on its own acts as though you had typed SEND PRIVATE, that is\r
+it will mark the message as personal and send it to the cluster node that\r
+that callsign is connected to.\r
+\r
+You can have more than one callsign in all of the SEND commands.\r
+\r
+You can have multiple qualifiers so that you can have for example:-\r
+\r
+<tscreen><verb>\r
+ SEND RR COPY 123 PRIVATE G1TLH G0RDI\r
+</verb></tscreen>\r
+\r
+which should send a copy of message 123 to G1TLH and G0RDI and you will\r
+receive a read receipt when they have read the message.\r
+\r
+SB is an alias for SEND NOPRIVATE (or send a bulletin in BBS speak)\r
+SP is an alias for SEND PRIVATE\r
+\r
+<sect1>set/address (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/address <your_address></bf> Record your postal address\r
+</tt>\r
+\r
+<P>\r
+Literally, record your address details on the cluster.\r
+\r
+<sect1>set/announce (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/announce</bf> Allow announce messages\r
+</tt>\r
+\r
+<P>\r
+Allow announce messages to arrive at your terminal.\r
+\r
+<sect1>set/arcluster (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/arcluster <node_call> [<node_call> ...]</bf> Make\r
+the node_call an AR-Cluster type node\r
+</tt>\r
+\r
+<P>\r
+Set the node_call as an AR-Cluster type node\r
+\r
+<sect1>set/baddx (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/baddx <call></bf> Stop words we do not wish to see in the callsign field\r
+of a dx spot being propagated\r
+</tt>\r
+\r
+<P>\r
+Setting a word as 'baddx' will prevent spots with that word in the callsign \r
+field of a DX spot from going any further. They will not be displayed and they \r
+will not be sent onto other nodes.\r
+\r
+The word must be wriiten in full, no wild cards are allowed eg:-\r
+\r
+<tscreen><verb>\r
+ set/baddx FORSALE VIDEO FR0G \r
+</verb></tscreen>\r
+\r
+To allow a word again, use the following command ...\r
+\r
+<tscreen><verb>\r
+ unset/baddx VIDEO\r
+</verb></tscreen>\r
+\r
+<sect1>set/badnode (6)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/badnode <node_call></bf> Stop spots from this node_call\r
+being propagated\r
+</tt>\r
+\r
+<P>\r
+Setting a callsign as a 'badnode' will prevent spots from that node \r
+going any further. They will not be displayed and they will not be \r
+sent onto other nodes.\r
+\r
+The call can be a full or partial call (or a prefix), eg:-\r
+\r
+<tscreen><verb>\r
+ set/badnode K1TTT \r
+</verb></tscreen>\r
+\r
+will stop anything from K1TTT (including any SSID's)\r
+\r
+<tscreen><verb>\r
+ unset/badnode K1TTT\r
+</verb></tscreen>\r
+\r
+will allow spots from him again.\r
+\r
+Use with extreme care. This command may well be superceded by FILTERing.\r
+\r
+<sect1>set/badspotter (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/badspotter <call></bf> Stop spots from this callsign being propagated\r
+</tt>\r
+\r
+<P>\r
+Setting a callsign as a 'badspotter' will prevent spots from this callsign \r
+going any further. They will not be displayed and they will not be \r
+sent onto other nodes.\r
+\r
+The call must be written in full, no wild cards are allowed eg:-\r
+\r
+<tscreen><verb>\r
+ set/badspotter VE2STN \r
+</verb></tscreen>\r
+\r
+will stop anything from VE2STN. If you want SSIDs as well then you must\r
+enter them specifically.\r
+\r
+<tscreen><verb>\r
+ unset/badspotter VE2STN\r
+</verb></tscreen>\r
+\r
+will allow spots from him again.\r
+\r
+Use with extreme care. This command may well be superceded by FILTERing.\r
+\r
+<sect1>set/badword (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/badword <word></bf> Stop things with this word being propogated\r
+</tt>\r
+\r
+<P>\r
+Setting a word as a 'badword' will prevent things like spots,\r
+announces or talks with this word in the the text part from going any\r
+further. They will not be displayed and they will not be sent onto\r
+other nodes.\r
+\r
+The word must be written in full, no wild cards are allowed eg:-\r
+\r
+ set/badword annihilate annihilated annihilation \r
+\r
+will stop anything with these words in the text.\r
+\r
+ unset/badword annihilated\r
+\r
+will allow text with this word again.\r
+\r
+\r
+<sect1>set/beep (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/beep</bf> Add beeps to terminal messages\r
+</tt>\r
+\r
+<P>\r
+Add a beep to DX and other terminal messages.\r
+\r
+<sect1>set/bbs (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/bbs <call> [<call>..]</bf>Make <call> a BBS\r
+</tt>\r
+\r
+<sect1>set/clx (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/clx <node_call> [<node_call> ...]</bf> Make\r
+the node_call a CLX type node\r
+</tt>\r
+\r
+<P>\r
+Set the node_call as a CLX type node\r
+\r
+<sect1>set/debug (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/debug <name></bf> Add a debug level to the debug set\r
+</tt>\r
+\r
+<P>\r
+You can choose to log several different levels. The levels are\r
+\r
+chan\r
+state\r
+msg\r
+cron\r
+connect\r
+\r
+You can show what levels you are logging with the <em>show/debug</em>\r
+command.\r
+\r
+You can remove a debug level with unset/debug <name>\r
+\r
+<sect1>set/dx (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/dx</bf>Allow DX messages to arrive at your terminal\r
+</tt>\r
+\r
+<P>\r
+You can stop DX messages with the <em>unset/dx</em> command\r
+\r
+<sect1>set/dxgrid (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/dxgrid</bf>Allow grid squares on the end of DX messages\r
+</tt>\r
+\r
+<P>\r
+Some logging programs do not like the additional information at\r
+the end of a DX spot. If this is the case, use the <em>unset/dxgrid</em>\r
+command to remove the grid squares.\r
+\r
+<sect1>set/dxnet (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/dxnet <node_call> [<node_call> ...]</bf> Make\r
+the node_call a DXNet type node\r
+</tt>\r
+\r
+<P>\r
+Set the node_call as a DXNet type node\r
+\r
+<sect1>set/echo (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/echo</bf> Make the cluster echo your input\r
+</tt>\r
+\r
+<P>\r
+If you are connected via a telnet session, different implimentations\r
+of telnet handle echo differently depending on whether you are \r
+connected via port 23 or some other port. You can use this command\r
+to change the setting appropriately. \r
+\r
+You can remove the echo with the <em>unset/echo</em> command\r
+\r
+The setting is stored in your user profile.\r
+\r
+YOU DO NOT NEED TO USE THIS COMMAND IF YOU ARE CONNECTED VIA AX25.\r
+\r
+<sect1>set/email (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/email <email_address></bf> Set email address(es) and forward your personals\r
+</tt>\r
+\r
+<P>\r
+If any personal messages come in for your callsign then you can use\r
+these commands to control whether they are forwarded onto your email\r
+address. To enable the forwarding do something like:-\r
+\r
+ SET/EMAIL mike.tubby@somewhere.com\r
+\r
+You can have more than one email address (each one separated by a space).\r
+Emails are forwarded to all the email addresses you specify.\r
+\r
+You can disable forwarding by:-\r
+\r
+ UNSET/EMAIL\r
+\r
+<sect1>set/here (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/here</bf> Set the here flag\r
+</tt>\r
+\r
+<P>\r
+Let others on the cluster know you are here by only displaying your\r
+callsign. If you are away from your terminal you can use the <em>unset/here</em>\r
+command to let people know you are away. This simply puts brackets\r
+around your callsign to indicate you are not available.\r
+\r
+<sect1>set/homenode (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/homenode <node_call></bf> Set your home cluster\r
+</tt>\r
+\r
+<P>\r
+Tell the cluster system where you normally connect to. Any Messages sent\r
+to you will normally find their way there should you not be connected.\r
+eg:-\r
+\r
+<tscreen><verb>\r
+ SET/HOMENODE gb7djk\r
+</verb></tscreen>\r
+\r
+<sect1>set/hops (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/hops <node_call> ann|spots|wwv|wcy <n></bf>\r
+Set hop count\r
+</tt>\r
+\r
+<P>\r
+Set the hop count for a particular type of broadcast for a node.\r
+\r
+This command allows you to set up special hop counts for a node \r
+for currently: announce, spots, wwv and wcy broadcasts.\r
+\r
+<tscreen><verb>\r
+eg:\r
+ set/hops gb7djk ann 10\r
+ set/hops gb7mbc spots 20\r
+</verb></tscreen>\r
+\r
+Set SHOW/HOPS for information on what is already set. This command\r
+creates a filter and works in conjunction with the filter system. \r
+\r
+<sect1>set/isolate (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/isolate <node call></bf> Isolate a node from the rest of the network\r
+</tt>\r
+\r
+<P>\r
+Connect a node to your system in such a way that you are a full protocol\r
+member of its network and can see all spots on it, but nothing either leaks\r
+out from it nor goes back into from the rest of the nodes connected to you.\r
+\r
+You can potentially connect several nodes in this way.\r
+\r
+You can see which nodes are isolated with the show/isolate (1) command.\r
+\r
+You can remove the isolation with the command unset/isolate.\r
+\r
+<sect1>set/language (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/language <language></bf> Set the language you wish to use\r
+</tt>\r
+\r
+<P>\r
+You can select the language that you want the cluster to use. Currently\r
+the languages available are <em>en</em> (English) and <em>nl</em> (Dutch).\r
+\r
+<sect1>set/location (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/location <lat and long></bf> Set your latitude and longitude\r
+</tt>\r
+\r
+<P>\r
+You can set your latitude and longitude manually or alternatively use the\r
+<em>set/qra</em> command which will do the conversion for you.\r
+\r
+<tscreen><verb>\r
+ set/location 54 04 N 2 02 E\r
+</verb></tscreen>\r
+\r
+\r
+<sect1>set/sys_location (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/sys_location <lat & long></bf> Set your cluster latitude and longitude\r
+</tt>\r
+\r
+<P>\r
+In order to get accurate headings and such like you must tell the system\r
+what your latitude and longitude is. If you have not yet done a SET/QRA\r
+then this command will set your QRA locator for you. For example:-\r
+\r
+<tscreen><verb>\r
+ SET/LOCATION 52 22 N 0 57 E\r
+</verb></tscreen>\r
+\r
+<sect1>set/logininfo (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/logininfo</bf> Show logins and logouts of nodes and users\r
+</tt>\r
+\r
+<P>\r
+Show users and nodes when they log in and out of the local cluster. You\r
+can stop these messages by using the <em>unset/logininfo</em> command.\r
+\r
+\r
+<sect1>set/lockout (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/lockout <call></bf> Stop a callsign connecting to the cluster\r
+</tt>\r
+\r
+<P>\r
+You can show who is locked out with the <em>show/lockout</em> command.\r
+To allow the user to connect again, use the <em>unset/lockout</em> command.\r
+\r
+<sect1>set/name (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/name <your_name></bf> Set your name\r
+</tt>\r
+\r
+<P>\r
+Tell the cluster what your name is, eg:-\r
+\r
+<tscreen><verb>\r
+ set/name Dirk\r
+</verb></tscreen>\r
+\r
+<sect1>set/node (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/node <call> [<call> ...]</bf> Make the callsign an AK1A cluster\r
+</tt>\r
+\r
+<P>\r
+Tell the system that the call(s) are to be treated as AK1A cluster and\r
+fed PC Protocol rather normal user commands.\r
+\r
+From version 1.41 you can also set the following types of cluster\r
+\r
+<tscreen><verb>\r
+ set/spider\r
+ set/dxnet\r
+ set/clx\r
+ set/arcluster\r
+</verb></tscreen>\r
+\r
+To see what your nodes are set to, use the <em>show/nodes</em> command.\r
+\r
+<sect1>set/obscount (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/obscount <count> <node call></bf> Set the 'pump-up' \r
+obsolescence counter\r
+</tt>\r
+\r
+<P>\r
+From version 1.35 onwards neighbouring nodes are pinged at regular intervals (see\r
+SET/PINGINTERVAL), usually 300 seconds or 5 minutes. There is a 'pump-up'\r
+counter which is decremented on every outgoing ping and then reset to\r
+the 'obscount' value on every incoming ping. The default value of this\r
+parameter is 2. \r
+\r
+What this means is that a neighbouring node will be pinged twice at \r
+(default) 300 second intervals and if no reply has been heard just before\r
+what would be the third attempt, that node is disconnected.\r
+\r
+If a ping is heard then the obscount is reset to the full value. Using\r
+default values, if a node has not responded to a ping within 15 minutes,\r
+it is disconnected.\r
+\r
+<sect1>set/page (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/page <n></bf> Set the number of lines per page\r
+</tt>\r
+\r
+<P>\r
+Tell the system how many lines you wish on a page when the number of lines\r
+of output from a command is more than this. The default is 20. Setting it\r
+explicitly to 0 will disable paging. \r
+\r
+<tscreen><verb>\r
+ SET/PAGE 30\r
+ SET/PAGE 0\r
+</verb></tscreen>\r
+\r
+The setting is stored in your user profile.\r
+\r
+<sect1>set/password (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/password</bf> Set your own password\r
+</tt>\r
+\r
+<P>\r
+This command only works for a 'telnet' user (currently). It will\r
+only work if you have a password already set. This initial password\r
+can only be set by the sysop.\r
+\r
+When you execute this command it will ask you for your old password,\r
+then ask you to type in your new password twice (to make sure you\r
+get it right). You may or may not see the data echoed on the screen\r
+as you type, depending on the type of telnet client you have.\r
+\r
+<sect1>set/password (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/password <callsign> <string></bf> Set a users password\r
+</tt>\r
+\r
+<P>\r
+The password for a user can only be set by a full sysop. The string\r
+can contain any characters. \r
+\r
+The way this field is used depends on context. If it is being used in\r
+the SYSOP command context then you are offered 5 random numbers and you\r
+have to supply the corresponding letters. This is now mainly for ax25\r
+connections.\r
+\r
+If it is being used on incoming telnet connections then, if a password\r
+is set or the:\r
+\r
+ set/var $main::passwdreq = 1\r
+\r
+command is executed in the startup script, then a password prompt is\r
+given after the normal 'login: ' prompt. \r
+\r
+The command "unset/password" is provided to allow a sysop to remove a\r
+users password completely in case a user forgets or loses their password.\r
+\r
+<sect1>set/pinginterval (9)\r
+\r
+<P>\r
+<tt><bf>set/pinginterval <time> <node call></bf> Set the ping time \r
+to neighbouring nodes\r
+</tt>\r
+\r
+<P>\r
+As from version 1.35 all neighbouring nodes are pinged at regular intervals\r
+in order to determine the rolling quality of the link and, in future, to\r
+affect routing decisions. The default interval is 300 secs or 5 minutes.\r
+\r
+You can use this command to set a different interval. Please don't. \r
+\r
+But if you do the value you enter is treated as minutes up 60 and seconds\r
+for numbers greater than that.\r
+\r
+This is used also to help determine when a link is down at the far end\r
+(as certain cluster software doesn't always notice), see SET/OBSCOUNT\r
+for more information.\r
+\r
+<sect1>set/privilege (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/privilege <n> <call> [<call> ...]</bf> Set the \r
+privilege level on a call\r
+</tt>\r
+\r
+<P>\r
+Set the privilege level on a callsign. The privilege levels that pertain\r
+to commands are as default:-\r
+\r
+<tscreen><verb>\r
+ 0 - normal user\r
+ 1 - allow remote nodes normal user RCMDs\r
+ 5 - various privileged commands (including shutdown, but not disc-\r
+ connect), the normal level for another node.\r
+ 8 - more privileged commands (including disconnect)\r
+ 9 - local sysop privilege. DO NOT SET ANY REMOTE USER OR NODE TO THIS\r
+ LEVEL.\r
+</verb></tscreen>\r
+\r
+If you are a sysop and you come in as a normal user on a remote connection\r
+your privilege will automatically be set to 0.\r
+\r
+<sect1>set/spider (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/spider <node_call> [<node_call> ...]</bf> Make\r
+the node_call a DXSpider type node\r
+</tt>\r
+\r
+<P>\r
+Set the node_call as a DXSpider type node\r
+\r
+<sect1>set/sys_qra (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/sys_qra <locator></bf> Set your cluster QRA locator\r
+</tt>\r
+\r
+<sect1>set/qra (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/qra <locator></bf> Set your QRA locator\r
+</tt>\r
+\r
+<P>\r
+Tell the system what your QRA (or Maidenhead) locator is. If you have not\r
+done a SET/LOCATION then your latitude and longitude will be set roughly\r
+correctly (assuming your locator is correct ;-). For example:-\r
+\r
+<tscreen><verb>\r
+ SET/QRA JO02LQ\r
+</verb></tscreen>\r
+\r
+<sect1>set/qth (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/qth <your QTH></bf> Set your QTH\r
+</tt>\r
+\r
+<P>\r
+Tell the system where your are. For example:-\r
+\r
+<tscreen><verb>\r
+ set/qth East Dereham, Norfolk\r
+</verb></tscreen>\r
+\r
+<sect1>set/register (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/register <call></bf> Mark a user as registered\r
+</tt>\r
+\r
+<P>\r
+Registration is a concept that you can switch on by executing the\r
+\r
+ set/var $main::regreq = 1 \r
+\r
+command (usually in your startup file)\r
+\r
+If a user is NOT registered then, firstly, instead of the normal\r
+motd file (/spider/data/motd) being sent to the user at startup, the\r
+user is sent the motd_nor file instead. Secondly, the non registered\r
+user only has READ-ONLY access to the node. The non-registered user\r
+cannot use DX, ANN etc. \r
+\r
+The only exception to this is that a non-registered user can TALK or\r
+SEND messages to the sysop.\r
+ \r
+To unset a user use the 'unset/register' command\r
+\r
+<sect1>set/talk (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/talk</bf> Allow talk messages to be seen at your console\r
+</tt>\r
+\r
+<P>\r
+Allow talk messages to arrive at your console. You can switch off\r
+talks with the <em>unset/talk</em> command.\r
+\r
+<sect1>set/wcy (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/wcy</bf> Allow WCY messages to be seen at your console\r
+</tt>\r
+\r
+<P>\r
+Allow WCY information to be seen at your console. You can switch off\r
+WCY messages with the <em>unset/wcy</em> command.\r
+\r
+<sect1>set/wwv (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/wwv</bf> Allow WWV messages to be seen at your console\r
+</tt>\r
+\r
+<P>\r
+Allow WWV information to be seen at your console. You can switch off\r
+WWV messages with the <em>unset/wwv</em> command.\r
+\r
+<sect1>set/wx (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>set/wx</bf> Allow WX messages to be seen at your console\r
+</tt>\r
+\r
+<P>\r
+Allow WX information to be seen at your console. You can switch off\r
+WX messages with the <em>unset/wx</em> command.\r
+\r
+<sect1>show/baddx (1)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/baddx</bf>Show all the bad dx calls in the system\r
+</tt>\r
+\r
+<P>\r
+Display all the bad dx callsigns in the system, see SET/BADDX\r
+for more information.\r
+\r
+<sect1>show/badnode (6)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/badnode</bf> Show all the bad nodes in the system\r
+</tt>\r
+\r
+<P>\r
+Display all the bad node callsigns in the system, see SET/BADNODE\r
+for more information.\r
+\r
+<sect1>show/badspotter (1)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/badspotter</bf> Show all the bad spotters in the system\r
+</tt>\r
+\r
+<P>\r
+Display all the bad spotter's callsigns in the system, see SET/BADSPOTTER\r
+for more information.\r
+\r
+<sect1>show/badword (1)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/badword</bf> Show all the bad words in the system\r
+</tt>\r
+\r
+<P>\r
+Display all the bad words in the system, see SET/BADWORD\r
+for more information.\r
+\r
+<sect1>show/configuration (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/configuration [<node>]</bf> Show all visible nodes and their users\r
+</tt>\r
+\r
+<P>\r
+This command allows you to see all the users that can be seen\r
+and the nodes to which they are connected. With the optional <em>node</em>,\r
+you can specify a particular node to look at.\r
+\r
+This command is normally abbreviated to: sh/c\r
+\r
+BE WARNED: the list that is returned can be VERY long\r
+\r
+<sect1>show/configuration/node (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/configuration/node</bf> Show all the nodes connected\r
+</tt>\r
+\r
+<P>\r
+Show all the nodes connected locally and the nodes they have connected.\r
+\r
+<sect1>show/connect (1)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/connect</bf> Show all the active connections\r
+</tt>\r
+\r
+<P>\r
+This command shows information on all the active connections known to\r
+the node. This command gives slightly more information than WHO.\r
+\r
+<sect1>show/date (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/date [<prefix>|<callsign>]</bf> Show\r
+the local time\r
+</tt>\r
+\r
+<P>\r
+This is very nearly the same as SHOW/TIME, the only difference the format\r
+of the date string if no arguments are given.\r
+\r
+If no prefixes or callsigns are given then this command returns the local\r
+time and UTC as the computer has it right now. If you give some prefixes\r
+then it will show UTC and UTC + the local offset (not including DST) at\r
+the prefixes or callsigns that you specify.\r
+\r
+<sect1>show/debug (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/debug</bf> Show what levels of debug you are logging\r
+</tt>\r
+\r
+<P>\r
+The levels can be set with <em>set/debug</em>\r
+\r
+<sect1>show/dx (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/dx [options]</bf> interrogate the spot database\r
+</tt>\r
+\r
+<P>\r
+If you just type SHOW/DX you will get the last so many spots\r
+(sysop configurable, but usually 10).\r
+ \r
+In addition you can add any number of these options in very nearly\r
+any order to the basic SHOW/DX command, they are:-\r
+\r
+<tscreen><verb> \r
+on <band> - eg 160m 20m 2m 23cm 6mm\r
+on <region> - eg hf vhf uhf shf (see SHOW/BANDS)\r
+ \r
+<number> - the number of spots you want\r
+<from>-<to> - <from> spot no <to> spot no in \r
+ the selected list\r
+ \r
+<prefix> - for a spotted callsign beginning with <prefix>\r
+*<suffix> - for a spotted callsign ending in <suffix>\r
+*<string>* - for a spotted callsign containing <string>\r
+ \r
+day <number> - starting <number> days ago\r
+day <from>-<to> - <from> days <to> days ago\r
+ \r
+info <text> - any spots containing <text> in the info or remarks\r
+ \r
+by <call> - any spots spotted by <call> (spotter <call> \r
+ is the same).\r
+\r
+qsl - this automatically looks for any qsl info on the call\r
+ held in the spot database.\r
+\r
+iota [<iota>] - If the iota island number is missing it will \r
+ look for the string iota and anything which looks like \r
+ an iota island number. If you specify then it will look \r
+ for that island.\r
+\r
+qra [<locator>] - this will look for the specific locator if \r
+ you specify one or else anything that looks like a locator.\r
+</verb></tscreen>\r
+ \r
+e.g. \r
+\r
+<tscreen><verb> \r
+ SH/DX 9m0\r
+ SH/DX on 20m info iota\r
+ SH/DX 9a on vhf day 30\r
+ SH/DX rf1p qsl\r
+ SH/DX iota \r
+ SH/DX iota eu-064\r
+ SH/DX qra jn86\r
+</verb></tscreen>\r
+\r
+<sect1>show/dxcc (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/dxcc <prefix></bf> Interrogate the spot database by country\r
+</tt>\r
+\r
+<P>\r
+This command takes the <prefix> (which can be a full or partial \r
+callsign if desired), looks up which internal country number it is\r
+and then displays all the spots as per SH/DX for that country.\r
+ \r
+The options for SHOW/DX also apply to this command. \r
+e.g. \r
+\r
+<tscreen><verb> \r
+ SH/DXCC G\r
+ SH/DXCC W on 20m info iota\r
+</verb></tscreen>\r
+\r
+<sect1>sh/dxstats (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>sh/dxstats</bf> Show the DX Statistics for last 31 days\r
+</tt>\r
+\r
+<P>\r
+Show the total DX spots for the last 31 days\r
+\r
+\r
+<sect1>show/files (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/files [<filearea> [<string>]]</bf> List\r
+the contents of a filearea\r
+</tt>\r
+\r
+<P>\r
+SHOW/FILES on its own will show you a list of the various fileareas\r
+available on the system. To see the contents of a particular file\r
+area type:-\r
+\r
+<tscreen><verb>\r
+ SH/FILES <filearea>\r
+</verb></tscreen>\r
+\r
+where <filearea> is the name of the filearea you want to see the \r
+contents of.\r
+\r
+You can also use shell globbing characters like '*' and '?' in a\r
+string to see a selection of files in a filearea eg:-\r
+\r
+<tscreen><verb>\r
+ SH/FILES bulletins arld*\r
+</verb></tscreen>\r
+\r
+See also TYPE - to see the contents of a file.\r
+\r
+<sect1>show/filter (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/filter</bf> Show the filters you have set\r
+</tt>\r
+\r
+<P>\r
+Show the contents of all the filters that are set by you. This command \r
+displays all the filters set - for all the various categories.\r
+\r
+<sect1>show/filter (extended for sysops) (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/filter <callsign></bf> Show the filters set by <callsign>\r
+</tt>\r
+\r
+<P>\r
+A sysop can look at any filters that have been set.\r
+\r
+<sect1>show/hfstats (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/hfstats</bf> Show the HF DX Statistics for last 31 days\r
+</tt>\r
+\r
+<P>\r
+Show the HF DX spots breakdown by band for the last 31 days\r
+\r
+<sect1>show/hftable (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/hftable</bf> Show the HF DX Spotter Table for your country\r
+</tt>\r
+\r
+<P>\r
+Show the HF DX Spotter table for your country for the last 31 days\r
+\r
+<sect1>show/hops (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/hops <node_call> [ann|spots|wcy|wwv|]</bf> Show the hop \r
+counts for a node\r
+</tt>\r
+\r
+<P>\r
+This command shows the hop counts set up for a node. You can specify\r
+which category you want to see. If you leave the category out then \r
+all the categories will be listed.\r
+\r
+<sect1>show/isolate (1)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/isolate</bf> Show a list of isolated nodes\r
+</tt>\r
+\r
+<P>\r
+Show which nodes are currently set to be isolated.\r
+\r
+<sect1>show/lockout (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/lockout</bf> Show a list of excluded callsigns\r
+</tt>\r
+\r
+<P>\r
+Show a list of callsigns that have been excluded (locked out) of the\r
+cluster locally with the <em>set/lockout</em> command\r
+\r
+<sect1>show/log (8)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/log [<callsign>]</bf> Show excerpts from the system log\r
+</tt>\r
+\r
+<P>\r
+This command outputs a short section of the system log. On its own\r
+it will output a general logfile. With the optional callsign it will\r
+show output from the log associated with that callsign.\r
+\r
+<sect1>show/moon (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/moon [<prefix>|<callsign>]</bf> Show moon\r
+rise and set times\r
+</tt>\r
+\r
+<P>\r
+Show the Moon rise and set times for a (list of) prefixes or callsigns, \r
+together with the azimuth and elevation of the sun currently at those\r
+locations.\r
+\r
+If you don't specify any prefixes or callsigns, it will show the times for\r
+your QTH (assuming you have set it with either SET/LOCATION or SET/QRA),\r
+together with the current azimuth and elevation.\r
+\r
+In addition, it will show the gain or loss dB relative to the nominal \r
+distance of 385,000Km due to the ellipsoidal nature of the orbit.\r
+\r
+If all else fails it will show the Moonrise and set times for the node\r
+that you are connected to. \r
+\r
+For example:-\r
+\r
+<tscreen><verb>\r
+ SH/MOON\r
+ SH/MOON G1TLH W5UN\r
+</verb></tscreen>\r
+\r
+<sect1>show/muf (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/muf <prefix> [<hours>][long]</bf> Show\r
+the likely propagation to <prefix>\r
+</tt>\r
+\r
+<P>\r
+This command allow you to estimate the likelihood of you contacting\r
+a station with the prefix you have specified. The output assumes a modest\r
+power of 20dBW and receiver sensitivity of -123dBm (about 0.15muV/10dB SINAD)\r
+\r
+The result predicts the most likely operating frequencies and signal\r
+levels for high frequency (shortwave) radio propagation paths on\r
+specified days of the year and hours of the day. It is most useful for\r
+paths between 250 km and 6000 km, but can be used with reduced accuracy\r
+for paths shorter or longer than this.\r
+\r
+The command uses a routine MINIMUF 3.5 developed by the U.S. Navy and\r
+used to predict the MUF given the predicted flux, day of the year,\r
+hour of the day and geographic coordinates of the transmitter and\r
+receiver. This routine is reasonably accurate for the purposes here,\r
+with a claimed RMS error of 3.8 MHz, but much smaller and less complex\r
+than the programs used by major shortwave broadcasting organizations,\r
+such as the Voice of America.\r
+\r
+The command will display some header information detailing its\r
+assumptions, together with the locations, latitude and longitudes and\r
+bearings. It will then show UTC (UT), local time at the other end\r
+(LT), calculate the MUFs, Sun zenith angle at the midpoint of the path\r
+(Zen) and the likely signal strengths. Then for each frequency for which\r
+the system thinks there is a likelihood of a circuit it prints a value.\r
+\r
+The value is currently a likely S meter reading based on the conventional\r
+6dB / S point scale. If the value has a '+' appended it means that it is\r
+1/2 an S point stronger. If the value is preceeded by an 'm' it means that\r
+there is likely to be much fading and by an 's' that the signal is likely\r
+to be noisy. \r
+\r
+By default SHOW/MUF will show the next two hours worth of data. You\r
+can specify anything up to 24 hours worth of data by appending the no of\r
+hours required after the prefix. For example:-\r
+\r
+<tscreen><verb>\r
+ SH/MUF W\r
+</verb></tscreen>\r
+\r
+produces:\r
+\r
+<tscreen><verb>\r
+ RxSens: -123 dBM SFI: 159 R: 193 Month: 10 Day: 21\r
+ Power : 20 dBW Distance: 6283 km Delay: 22.4 ms\r
+ Location Lat / Long Azim\r
+ East Dereham, Norfolk 52 41 N 0 57 E 47\r
+ United-States-W 43 0 N 87 54 W 299\r
+ UT LT MUF Zen 1.8 3.5 7.0 10.1 14.0 18.1 21.0 24.9 28.0 50.0\r
+ 18 23 11.5 -35 mS0+ mS2 S3\r
+ 19 0 11.2 -41 mS0+ mS2 S3\r
+</verb></tscreen>\r
+\r
+indicating that you will have weak, fading circuits on top band and \r
+80m but usable signals on 40m (about S3).\r
+\r
+inputting:-\r
+\r
+<tscreen><verb>\r
+ SH/MUF W 24\r
+</verb></tscreen>\r
+\r
+will get you the above display, but with the next 24 hours worth of\r
+propagation data.\r
+\r
+<tscreen><verb>\r
+ SH/MUF W L 24\r
+ SH/MUF W 24 Long\r
+</verb></tscreen>\r
+\r
+Gives you an estimate of the long path propagation characterics. It\r
+should be noted that the figures will probably not be very useful, nor\r
+terrible accurate, but it is included for completeness.\r
+\r
+<sect1>show/newconfiguration (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/newconfiguration [<node>]</bf> Show all the nodes and users visible\r
+</tt>\r
+\r
+<P>\r
+This command allows you to see all the users that can be seen\r
+and the nodes to which they are connected. \r
+\r
+This command produces essentially the same information as \r
+SHOW/CONFIGURATION except that it shows all the duplication of\r
+any routes that might be present It also uses a different format\r
+which may not take up quite as much space if you don't have any\r
+loops.\r
+\r
+BE WARNED: the list that is returned can be VERY long\r
+\r
+<sect1>show/newconfiguration/node (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/newconfiguration/node</bf> Show all the nodes connected locally\r
+</tt>\r
+\r
+<P>\r
+Show all the nodes connected to this node in the new format.\r
+\r
+<sect1>show/node (1)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/node [<node_call> ...]</bf> Show the type and version\r
+number of nodes\r
+</tt>\r
+\r
+<P>\r
+Show the type and version (if connected) of the nodes specified on the\r
+command line. If no callsigns are specified then a sorted list of all\r
+the non-user callsigns known to the system will be displayed.\r
+\r
+<sect1>show/prefix (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/prefix <callsign></bf> Interrogate the prefix database\r
+</tt>\r
+\r
+<P>\r
+This command takes the <callsign> (which can be a full or partial \r
+callsign or a prefix), looks up which internal country number \r
+it is and then displays all the relevant prefixes for that country\r
+together with the internal country no, the CQ and ITU regions. \r
+\r
+See also SHOW/DXCC\r
+\r
+\r
+<sect1>show/program (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/program</bf> Show the locations of all the included program modules\r
+</tt>\r
+\r
+<P>\r
+Show the name and location where every program module was load from. This\r
+is useful for checking where you think you have loaded a .pm file from.\r
+\r
+<sect1>show/qra (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/qra <locator> [<locator>]</bf> Show the distance\r
+between locators<newline>\r
+<bf>show/qra <lat> <long></bf> Convert latitude and longitude to \r
+a locator\r
+</tt>\r
+\r
+<P>\r
+This is a multipurpose command that allows you either to calculate the\r
+distance and bearing between two locators or (if only one locator is\r
+given on the command line) the distance and beraing from your station\r
+to the locator. For example:-\r
+\r
+<tscreen><verb>\r
+SH/QRA IO92QL \r
+SH/QRA JN06 IN73\r
+</verb></tscreen>\r
+\r
+The first example will show the distance and bearing to the locator from\r
+yourself, the second example will calculate the distance and bearing from\r
+the first locator to the second. You can use 4 or 6 character locators.\r
+\r
+It is also possible to convert a latitude and longitude to a locator by \r
+using this command with a latitude and longitude as an argument, for\r
+example:-\r
+\r
+<tscreen><verb>\r
+SH/QRA 52 41 N 0 58 E\r
+</verb></tscreen>\r
+\r
+<sect1>show/qrz (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/qrz <callsign></bf> Show any callbook details on a callsign\r
+</tt>\r
+\r
+<P>\r
+This command queries the QRZ callbook server on the internet\r
+and returns any information available for that callsign. This service\r
+is provided for users of this software by http://www.qrz.com \r
+\r
+<sect1>show/registered (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/registered [<prefix>[</bf> Show the registered users\r
+</tt>\r
+\r
+<sect1>show/route (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/route <callsign></bf> Show the route to <callsign>\r
+</tt>\r
+\r
+<P>\r
+This command allows you to see to which node the callsigns specified are\r
+connected. It is a sort of inverse sh/config.\r
+\r
+<tscreen><verb>\r
+ sh/route n2tly\r
+</verb></tscreen>\r
+\r
+<sect1>show/satellite (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/satellite <name> [<hours> <interval>]</bf>\r
+Show satellite tracking data\r
+</tt>\r
+\r
+<P>\r
+Show the tracking data from your location to the satellite of your choice\r
+from now on for the next few hours.\r
+\r
+If you use this command without a satellite name it will display a list\r
+of all the satellites known currently to the system. \r
+\r
+If you give a name then you can obtain tracking data of all the passes\r
+that start and finish 5 degrees below the horizon. As default it will\r
+give information for the next three hours for every five minute period.\r
+\r
+You can alter the number of hours and the step size, within certain \r
+limits. \r
+\r
+Each pass in a period is separated with a row of '-----' characters\r
+\r
+So for example:-\r
+\r
+<tscreen><verb>\r
+SH/SAT AO-10 \r
+SH/SAT FENGYUN1 12 2\r
+</verb></tscreen>\r
+\r
+<sect1>show/sun (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/sun [<prefix>|<callsign>]</bf> Show\r
+sun rise and set times\r
+</tt>\r
+\r
+<P>\r
+Show the sun rise and set times for a (list of) prefixes or callsigns, \r
+together with the azimuth and elevation of the sun currently at those\r
+locations.\r
+\r
+If you don't specify any prefixes or callsigns, it will show the times for\r
+your QTH (assuming you have set it with either SET/LOCATION or SET/QRA),\r
+together with the current azimuth and elevation.\r
+\r
+If all else fails it will show the sunrise and set times for the node\r
+that you are connected to. \r
+\r
+For example:-\r
+\r
+<tscreen><verb>\r
+ SH/SUN\r
+ SH/SUN G1TLH K9CW ZS\r
+</verb></tscreen>\r
+\r
+<sect1>show/time (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/time [<prefix>|<callsign>]</bf> Show\r
+the local time\r
+</tt>\r
+\r
+<P>\r
+If no prefixes or callsigns are given then this command returns the local\r
+time and UTC as the computer has it right now. If you give some prefixes\r
+then it will show UTC and UTC + the local offset (not including DST) at\r
+the prefixes or callsigns that you specify.\r
+\r
+<sect1>show/vhfstats (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/vhfstats</bf> Show the VHF DX Statistics for last 31 days\r
+</tt>\r
+\r
+<P>\r
+Show the VHF DX spots breakdown by band for the last 31 days\r
+\r
+<sect1>show/vhftable (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/vhftable</bf> Show the VHF DX Spotter Table for your country\r
+</tt>\r
+\r
+<P>\r
+Show the VHF DX Spotter table for your country for the last 31 days\r
+\r
+<sect1>show/wcy (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/wcy</bf> Show the last 10 WCY broadcasts<newline>\r
+<bf>show/wcy <n></bf> Show the last <n> WCY broadcasts\r
+</tt>\r
+\r
+<P>\r
+Display the most recent WCY information that has been received by the system\r
+\r
+<sect1>show/wwv (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>show/wwv</bf> Show the last 10 WWV broadcasts<newline>\r
+<bf>show/wwv <n></bf> Show the last <n> WWV broadcasts\r
+</tt>\r
+\r
+<P>\r
+Display the most recent WWV information that has been received by the system\r
+\r
+\r
+<sect1>shutdown (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>shutdown</bf> Shutdown the cluster\r
+</tt>\r
+\r
+<P>\r
+Shutdown the cluster and disconnect all the users. If you have Spider\r
+set to respawn in /etc/inittab it will of course restart.\r
+\r
+<sect1>spoof (9)\r
+\r
+<P>\r
+<tt>\r
+<bf>spoof <callsign> <command></bf> Run commands as another user\r
+</tt>\r
+\r
+<P>\r
+This is a very simple yet powerful command for the sysop. It allows you to\r
+issue commands as if you were a different user. This is very useful for the\r
+kind of things that users seem to always get wrong.. like home_node for\r
+example.\r
+\r
+<sect1>stat/db (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>stat/db <dbname></bf> Show the status of a database\r
+</tt>\r
+\r
+<P>\r
+Show the internal status of a database descriptor.\r
+\r
+Depending on your privilege level you will see more or less information. \r
+This command is unlikely to be of much use to anyone other than a sysop.\r
+\r
+<sect1>stat/channel (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>stat/channel <callsign></bf> Show the status of a channel on the cluster\r
+</tt>\r
+\r
+<P>\r
+Show the internal status of the channel object either for the channel that \r
+you are on or else for the callsign that you asked for.\r
+\r
+Only the fields that are defined (in perl term) will be displayed.\r
+\r
+<sect1>stat/msg (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>stat/msg <msgno></bf> Show the status of a message\r
+</tt>\r
+\r
+<P>\r
+This command shows the internal status of a message and includes information\r
+such as to whom it has been forwarded, its size, origin etc etc.\r
+\r
+<P>\r
+If no message number is given then the status of the message system is \r
+displayed.\r
+\r
+<sect1>stat/route_node (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>stat/route_node <callsign></bf> Show the data in a Route::Node object\r
+</tt>\r
+\r
+<sect1>stat/route_user (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>stat/route_user <callsign></bf> Show the data in a Route::User object\r
+</tt>\r
+\r
+<sect1>stat/user (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>stat/user <callsign></bf> Show the full status of a user\r
+</tt>\r
+\r
+<P>\r
+Shows the full contents of a user record including all the secret flags\r
+and stuff.\r
+\r
+Only the fields that are defined (in perl term) will be displayed.\r
+\r
+<sect1>sysop (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>sysop</bf> Regain your privileges if you login remotely\r
+</tt>\r
+\r
+<P>\r
+The system automatically reduces your privilege level to that of a\r
+normal user if you login in remotely. This command allows you to\r
+regain your normal privilege level. It uses the normal system: five\r
+numbers are returned that are indexes into the character array that is\r
+your assigned password (see SET/PASSWORD). The indexes start from\r
+zero.\r
+\r
+You are expected to return a string which contains the characters\r
+required in the correct order. You may intersperse those characters\r
+with others to obscure your reply for any watchers. For example (and\r
+these values are for explanation :-):\r
+\r
+<tscreen><verb>\r
+ password = 012345678901234567890123456789\r
+ > sysop\r
+ 22 10 15 17 3\r
+</verb></tscreen>\r
+\r
+you type:-\r
+\r
+<tscreen><verb>\r
+ aa2bbbb0ccc5ddd7xxx3n\r
+ or 2 0 5 7 3\r
+ or 20573\r
+</verb></tscreen>\r
+\r
+They will all match. If there is no password you will still be offered\r
+numbers but nothing will happen when you input a string. Any match is\r
+case sensitive.\r
+\r
+<sect1>talk (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>talk <callsign></bf> Enter talk mode with <callsign><newline>\r
+<bf>talk <callsign> <text></bf> Send a text message to <callsign><newline>\r
+<bf>talk <callsign> > <node_call> [<text>]</bf>\r
+Send a text message to <callsign> via <node_call>\r
+</tt>\r
+\r
+<P>\r
+Send a short message to any other station that is visible on the cluster\r
+system. You can send it to anyone you can see with a SHOW/CONFIGURATION \r
+command, they don't have to be connected locally.\r
+\r
+The second form of TALK is used when other cluster nodes are connected\r
+with restricted information. This usually means that they don't send \r
+the user information usually associated with logging on and off the cluster.\r
+\r
+If you know that G3JNB is likely to be present on GB7TLH, but you can only\r
+see GB7TLH in the SH/C list but with no users, then you would use the\r
+second form of the talk message.\r
+\r
+If you want to have a ragchew with someone you can leave the text message\r
+out and the system will go into 'Talk' mode. What this means is that a\r
+short message is sent to the recipient telling them that you are in a 'Talking' \r
+frame of mind and then you just type - everything you send will go to the \r
+station that you asked for. \r
+\r
+All the usual announcements, spots and so on will still come out on your\r
+terminal.\r
+\r
+If you want to do something (such as send a spot) you precede the normal \r
+command with a '/' character, eg:-\r
+\r
+<tscreen><verb>\r
+ /DX 14001 G1TLH What's a B class licensee doing on 20m CW?\r
+ /HELP talk\r
+</verb></tscreen>\r
+\r
+To leave talk mode type:\r
+ \r
+<tscreen><verb>\r
+ /EX\r
+</verb></tscreen>\r
+\r
+<sect1>type (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>type <filearea>/<name></bf> Look at a file in one of the fileareas\r
+</tt>\r
+\r
+<P>\r
+Type out the contents of a file in a filearea. So, for example, in \r
+filearea 'bulletins' you want to look at file 'arld051' you would \r
+enter:-\r
+\r
+<tscreen><verb>\r
+ TYPE bulletins/arld051\r
+</verb></tscreen>\r
+\r
+See also SHOW/FILES to see what fileareas are available and a \r
+list of content.\r
+\r
+<sect1>who (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>who</bf> Show who is physically connected locally\r
+</tt>\r
+\r
+<P>\r
+This is a quick listing that shows which callsigns are connected and\r
+what sort of connection they have\r
+\r
+<sect1>wx (0)\r
+\r
+<P>\r
+<tt>\r
+<bf>wx <text></bf> Send a weather message to local users<newline>\r
+<bf>wx full <text> </bf> Send a weather message to all cluster users\r
+</tt>\r
+\r
+<P>\r
+Weather messages can sometimes be useful if you are experiencing an extreme\r
+that may indicate enhanced conditions\r
+\r
+<sect1>wx (enhanced for sysops) (5)\r
+\r
+<P>\r
+<tt>\r
+<bf>wx sysop <text></bf> Send a weather message to other clusters only\r
+</tt>\r
+\r
+<P>\r
+Send a weather message only to other cluster nodes and not to general users.\r
+\r
+\r
+\r
+</article>\r
projects / spider.git / commitdiff