<!-- Title information -->
-<title>The DXSpider Administration Manual v1.48</title>
+<title>The DXSpider Administration Manual v1.49</title>
<author>Ian Maude, G0VGS, (ianmaude@btinternet.com)</author>
-<date>Version 1.48 August 2001 revision 1.1</date>
+<date>November 2001 revision 1.1</date>
<abstract>
A reference for SysOps of the DXSpider DXCluster program.
<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
+<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 is filtering the node
+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 PC protocol frames, to do with user and node management, pass to
-each of your partner nodes. You can also limit what comes into your
-node from your partners. You can even control the settings that your
-partner node has for the routing information that it sends to you
+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
explained further on.
<p>
-The first thing that you must do is determine whether you need to do route filtering <bf>at all</bf>. If you are a "normal" node with two or three partners
-and you arranged in an "official" non-looping tree type network, then <bf>you do
-not need to do route filtering</bf> and you will feel a lot better for not
-getting involved. If you are successfully using <it>isolation</it> then you
-also probably don't need to use route filtering.
+The 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>
-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.
+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
</verb></tscreen>
Please be careful if you alter this setting, it will affect
-<bf><it>ALL</it></bf> your links!
+<bf><it>ALL</it></bf> your links! Remember, this is a <it>default</it>
+filter for node connections, not a <it>per link</it> default.
<p>
For the default routing filter then you have two real choices: either
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:-
+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
Here are some examples of route filters ...
<tscreen><verb>
-rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes)
-rej/route all (equiv to [very] restricted mode)
+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>
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:-
+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
PC16s for my local users).
<p>
-It is possible to do <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.
+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
If you alter the file during runtime, the command <em>load/hops</em> will
bring your changes into effect.
+<sect1>Hop Control on Specific Nodes
+
+<p>You can set a callsign specific hop count for any of the standard filter
+options so:-
+
+<tscreen><verb>
+set/hops gb7djk spot 4
+set/hops node_default route 10
+set/hops gb7baa wcy 5
+</verb></tscreen>
+
+all work on their specific area of the protocol.
+
+<p>
+The <em>set/hops</em> command overrides any hops that you have set otherwise.
+
+<p>
+You can set what hops have been set using the <em>show/hops</em> command.
+
<sect1>Isolating networks
<P>
node and it will be routed across.
<P>
-The only limitation currently is that non-private messages cannot be passed down
-isolated links regardless of whether they are generated locally. This will change
-when the bulletin routing facility is added.
-
-<P>
-If you use isolate on a node connection you will continue to receive all
-information from the isolated partner, however you will not pass any information
-back to the isolated node. There are times when you would like to forward only
-spots across a link (maybe during a contest for example). To do this, isolate
-the node in the normal way and put in a filter in the /spider/filter/spots
-directory to override the isolate. This filter can be very simple and consists
-of just one line ....
-
-<tscreen><verb>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
-</verb></tscreen>
+If you use isolate on a node connection you will continue to receive
+all information from the isolated partner, however you will not pass
+any information back to the isolated node. There are times when you
+would like to forward only spots across a link (maybe during a contest
+for example). To do this, isolate the node in the normal way and use
+an <em>acc/spot >call< all</em> filter to override the isolate.
<sect>Other filters
the other cluster nodes that we are linked to. This is usually because of
rules and regulations pertaining to items for sale etc in a particular country.
-<sect1>Filtering DX callouts (Depricated)
-<P>
-<bf><it>From version 1.47, this method is replaced by the command set/baddx</it></bf>
+<sect1>Filtering words from text fields in Announce, Talk and DX spots
-<P>
-In the same way as mail, there are some types of spot we do not wish to pass on
-to users or linked cluster nodes. In the /spider/data directory you will find
-a file called baddx.pl.issue. Rename this to baddx.pl and edit the file. The
-original looks like this ....
+<p>
+From version 1.48 onwards the interface to this has changed. You can now
+use the commands <em>set/badword</em> to add words that you are not prepared
+to see on the cluster, <em>unset/badword</em> to allow that word again and
+<em>show/badword</em> to list the words that you have set.
-<tscreen><verb>
+<p>
+If you have a previous <em>/spider/data/badwords</em>, the first time you start
+the node, it will read and convert this file to the new commands. The old style
+file will then be removed.
-# the list of dx spot addresses that we don't store and don't pass on
+<sect1>Stopping (possibly bad) DX Spots from Nodes or Spotters
+<p>
+There are a number of commands that control whether a spot progresses
+any further by regarding it as "bad" in some way.
-package DXProt;
+<p>
+A DX Spot has a number of fields which can be checked to see whether they
+contain "bad" values, they are: the DX callsign itself, the Spotter and
+the Originating Node.
-@baddx = qw
-
- FROG
- SALE
- FORSALE
- WANTED
- P1RATE
- PIRATE
- TEST
- DXTEST
- NIL
- NOCALL
-);
-</verb></tscreen>
+<p>
+There are a set of commands which allow the sysop to control whether a
+spot continues:-
-<P>
-Again, this is simply a list of names we do not want to see in the spotted
-field of a DX callout.
+<tscreen><verb>
+set/baddx
+set/badspotter
+set/badnode
+</verb></tscreen>
+These work in the same as the <em>set/badword</em> command, you can add
+any words or callsigns or whatever to the appropriate database. For
+example, to stop a spot from a particular node you do:
-<sect1>Filtering words from text fields in Announce, Talk and DX spots
+<tscreen><verb>
+set/badnode gb7djk gb7dxc
+</verb></tscreen>
-<P>
-Create a file in /spider/data called <em>badwords</em>. The format is quite
-simple. Lines beginning with # are ignored so comments can be added. An
-example file is below ...
+a bad spotter:
<tscreen><verb>
-# Below is a list of words we do not wish to see on the cluster
-grunge grunged grunging
-splodge splodger splodging
-grince
-fluffle
+set/badspotter b0mb p1rat nocall
</verb></tscreen>
-Multiple words can be used on the same line as shown. Obviously these
-are just examples :-)
+and some bad dx:
-<P>
-You can reload the file from the cluster prompt as sysop with load/badwords.
+<tscreen><verb>
+set/baddx video wsjt
+</verb></tscreen>
+
+You can remove a word using the appropriate unset command
+(<em>unset/baddx, unset/badspotter, unset/badnode</em>) or list them
+using one of <em>show/baddx, show/badspotter</em> and
+<em>show/badnode</em>.
<sect>Mail
Make sure you only send mail to the clusters that want it by using the
Forward.pl file very carefully.
+<sect>Scripts
+
+<p>
+From 1.48 onwards it will become increasingly possible to control DXSpider's
+operation with scripts of various kinds.
+
+<P>
+The directory /spider/scripts is where it all happens and is used for several
+things. Firstly it contains a file called startup that can be used to call
+in any changes to the cluster from the default settings on startup. This
+script is executed immediately after all initialisation of the node is done
+but before any connections are possible. Examples of this include how many
+spots it is possible to get with the sh/dx command, whether you want
+registration/passwords to be permanently on etc. An example file is shown
+below and is included in the distribution as startup.issue.
+
+<tscreen><verb>
+#
+# startup script example
+#
+# set maximum no of spots allowed to 100
+# set/var $Spot::maxspots = 1
+#
+# Set registration on
+# set/var $main::reqreg = 1
+#
+# Set passwords on
+# set/var $main::passwdreq = 1
+#
+</verb></tscreen>
+
+<P>
+As usual, any text behind a # is treated as a comment and not read.
+
+Secondly, it is used to store the login scripts for users and nodes. Currently
+this can only be done by the sysop but it is envisaged that eventually users will
+be able to set their own. An example is included in the distibution but here is
+a further example.
+
+<tscreen><verb>
+#
+# G0FYD
+#
+blank +
+sh/wwv 3
+blank +
+sh/dx
+blank +
+t g0jhc You abt?
+blank +
+</verb></tscreen>
+
+The lines in between commands can simply insert a blank line or a character
+such as a + sign to make the output easier to read. Simply create this script
+with your favourite editor and save it with the callsign of the user as the
+filename. Filenames should always be in lower case.
+
+<P>
+Commands can be inserted in the same way for nodes. A node may wish a series
+of commands to be issued on login, such as a merge command for example.
+
+<P>
+Thirdly, there are 2 default scripts for users and nodes who do not have a
+specifically defined script. These are <em>user_default</em> and
+<em>node_default</em>
+
<sect>Databases
<P>
and edit it to say whatever you want. It is purely a text file and will be
sent automatically to anyone logging in to the cluster.
+<sect1>MOTD_NOR
+
+<P>
+This message of the day file lives in the same directory as the standard
+motd file but is only sent to non-registered users. Once registered they
+will receive the same message as any other user.
+
<sect1>Downtime message
<P>
the setup. Many thanks to Fred Lloyd, the proprieter of
<htmlurl url="http://www.qrz.com" name="qrz.com"> for allowing this access.
+<sect>Security
+
+<P>
+From version 1.49 DXSpider has some additional security features. These
+are not by any means meant to be exhaustive, however they do afford some
+security against piracy. These two new features can be used independently
+of each other or in concert to tighten the security.
+
+<sect1>Registration
+
+<P>
+The basic principle of registration is simple. If a user is not registered
+by the sysop, then they have read-only access to the cluster. The only
+thing they can actually send is a talk or a message to the sysop. In
+order for them to be able to spot, send announces or talks etc the sysop
+must register them with the <em>set/register</em> command, like this ...
+
+<tscreen><verb>
+set/register g0vgs
+</verb></tscreen>
+
+The user g0vgs can now fully use the cluster. In order to enable
+registration, you can issue the command ...
+
+<tscreen><verb>
+set/var $main::reqreg = 1
+</verb></tscreen>
+
+Any users that are not registered will now see the motd_nor file rather
+than the motd file as discussed in the Information, files and useful
+programs section.
+
+<P>
+Entering this line at the prompt will only last for the time the cluster
+is running of course and would not be present on a restart. To make the
+change permanent, add the above line to /spider/scripts/startup. To
+read more on the startup file, see the section on Information, files
+and useful programs.
+
+<P>
+To unregister a user use <em>unset/register</em> and to show the list
+of registered users, use the command <em>show/register</em>.
+
+<sect1>Passwords
+
+<P>
+At the moment, passwords only affect users who login to a DXSpider
+cluster node via telnet. If a user requires a password, they can
+either set it themselves or have the sysop enter it for them by using
+the <em>set/password</em> command. Any users who already have passwords,
+such as remote sysops, will be asked for their passwords automatically
+by the cluster. Using passwords in this way means that the user has a
+choice on whether to have a password or not. To force the use of
+passwords at login, issue the command ...
+
+<tscreen><verb>
+set/var $main::passwdreq = 1
+</verb></tscreen>
+
+at the cluster prompt. This can also be added to the /spider/scripts/startup
+file as above to make the change permanent.
+
+<P>
+Of course, if you do this you will have to assign a password for each of
+your users. If you were asking them to register, it is anticipated that
+you would ask them to send you a message both to ask to be registered and
+to give you the password they wish to use.
+
+<P>
+Should a user forget their password, it can be reset by the sysop by
+first removing the existing password and then setting a new one like so ...
+
+<tscreen><verb>
+unset/password g0vgs
+set/password g0vgs new_password
+</verb></tscreen>
+
<sect>CVS
<P>
sources by using a few simple commands.
<P>
-THIS IS NOT FOR THE FAINT HEARTED!!! ONLY DO THIS IF YOU HAVE A TEST
-INSTALLATION OR ARE WILLING TO HAVE YOUR CLUSTER CRASH ON YOU!!!
-THIS MUST BE CONSIDERED AT LEAST BETA TESTING AND MAYBE EVEN ALPHA!!
-YOU HAVE BEEN WARNED!!!
-
-<P>
-DID I MENTION..... ONLY DO THIS IF YOU ARE WILLING TO ACCEPT THE
-CONSEQUENCES!!!
+Please be aware that if you update your system using CVS, it is possible that
+you could be running code that is very beta and not fully tested. There is
+a possibility that it could be unstable.
<P>
I am of course assuming that you have a machine with both DXSpider and
Order is not important.
+<sect1>clear/announce (8)
+
+<P>
+<tt>
+<bf>clear/announce [input] <callsign> [0-9|all]</bf> Clear an announce filter line
+</tt>
+
+<P>
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
+
+<sect1>clear/route (8)
+
+<P>
+<tt>
+<bf>clear/route [input] ^lt;callsign> [0-9|all]</bf> Clear a route filter line
+</tt>
+
+<P>
+This command allows you to clear (remove) a line in a route filter or to
+remove the whole filter.
+
+see CLEAR/SPOTS for a more detailed explanation.
+
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
+
<sect1>clear/spots (0)
<P>
the filter will be completely removed.
+<sect1>clear/spots (extended for sysops) (8)
+
+<P>
+<tt>
+<bf>clear/spots [input] <callsign> [0-9|all]</bf> Clear a spot filter line
+</tt>
+
+<P>
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
+
+<sect1>clear/wcy (0)
+
+<P>
+<tt>
+<bf>clear/wcy [1|all]</bf> Clear a WCY filter line
+</tt>
+
+<P>
+This command allows you to clear (remove) a line in a WCY filter or to
+remove the whole filter.
+
+see CLEAR/SPOTS for a more detailed explanation.
+
+<sect1>clear/wcy (extended for sysops) (8)
+
+<P>
+<tt>
+<bf>clear/wcy [input] <callsign> [0-9|all]</bf> Clear a WCY filter line
+</tt>
+
+<P>
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
+
+<sect1>clear/wwv (0)
+
+<P>
+<tt>
+<bf>clear/wwv [1|all]</bf> Clear a WWV filter line
+</tt>
+
+<P>
+This command allows you to clear (remove) a line in a WWV filter or to
+remove the whole filter.
+
+see CLEAR/SPOTS for a more detailed explanation.
+
+<sect1>clear/wwv (extended for sysops) (8)
+
+<P>
+<tt>
+<bf>clear/wwv [input] <callsign> [0-9|all]</bf> Clear a WWV filter line
+</tt>
+
+<P>
+A sysop can clear an input or normal output filter for a user or the
+node_default or user_default.
<sect1>connect (5)
It will interrupt the cluster just after the debug command has finished.
+<sect1>delete/user (9)
+
+<P>
+<tt>
+<bf>delete/user <callsign></bf> Delete a user from the User Database
+</tt>
+
+<P>
+This command will completely remove a one or more users from the database.
+
+There is NO SECOND CHANCE.
+
+It goes without saying that you should use this command CAREFULLY!
+
+
<sect1>directory (0)
<P>
BE WARNED: this will write to any file you have write access to. No check is
made on the filename (if any) that you specify.
+<sect1>filtering (0)
+
+<P>
+<tt>
+<bf>filtering</bf> Filtering things in DXSpider
+</tt>
+
+<P>
+There are a number of things you can filter in the DXSpider system. They
+all use the same general mechanism.
+
+In general terms you can create a 'reject' or an 'accept' filter which
+can have up to 10 lines in it. You do this using, for example:-
+
+ accept/spots .....
+ reject/spots .....
+
+where ..... are the specific commands for that type of filter. There
+are filters for spots, wwv, announce, wcy and (for sysops)
+connects. See each different accept or reject command reference for
+more details.
+
+There is also a command to clear out one or more lines in a filter and
+one to show you what you have set. They are:-
+
+ clear/spots 1
+ clear/spots all
+
+and
+
+ show/filter
+
+There is clear/xxxx command for each type of filter.
+
+For now we are going to use spots for the examples, but you can apply
+the principles to all types of filter.
+
+There are two main types of filter 'accept' or 'reject'; which you use
+depends entirely on how you look at the world and what is least
+writing to achieve what you want. Each filter has 10 lines (of any
+length) which are tried in order. If a line matches then the action
+you have specified is taken (ie reject means ignore it and accept
+means gimme it).
+
+The important thing to remember is that if you specify a 'reject'
+filter (all the lines in it say 'reject/spots' (for instance) then if
+a spot comes in that doesn't match any of the lines then you will get
+it BUT if you specify an 'accept' filter then any spots that don't
+match are dumped. For example if I have a one line accept filter:-
+
+ accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
+
+then automatically you will ONLY get VHF spots from or to CQ zones 14
+15 and 16. If you set a reject filter like:
+
+ reject/spots on hf/cw
+
+Then you will get everything EXCEPT HF CW spots, If you am interested in IOTA
+and will work it even on CW then you could say:-
+
+ reject/spots on hf/cw and not info iota
+
+But in that case you might only be interested in iota and say:-
+
+ accept/spots not on hf/cw or info iota
+
+which is exactly the same. You should choose one or the other until
+you are confortable with the way it works. Yes, you can mix them
+(actually you can have an accept AND a reject on the same line) but
+don't try this at home until you can analyse the results that you get
+without ringing up the sysop for help.
+
+You can arrange your filter lines into logical units, either for your
+own understanding or simply convenience. I have one set frequently:-
+
+ reject/spots 1 on hf/cw
+ reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)
+
+What this does is to ignore all HF CW spots (being a class B I can't
+read any CW and couldn't possibly be interested in HF :-) and also
+rejects any spots on VHF which don't either originate or spot someone
+in Europe.
+
+This is an exmaple where you would use the line number (1 and 2 in
+this case), if you leave the digit out, the system assumes '1'. Digits
+'0'-'9' are available.
+
+You can leave the word 'and' out if you want, it is implied. You can
+use any number of brackets to make the 'expression' as you want
+it. There are things called precedence rules working here which mean
+that you will NEED brackets in a situation like line 2 because,
+without it, will assume:-
+
+ (on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16
+
+annoying, but that is the way it is. If you use OR - use
+brackets. Whilst we are here CASE is not important. 'And BY_Zone' is
+just 'and by_zone'.
+
+If you want to alter your filter you can just redefine one or more
+lines of it or clear out one line. For example:-
+
+ reject/spots 1 on hf/ssb
+
+or
+
+ clear/spots 1
+
+To remove the filter in its entirty:-
+
+ clear/spots all
+
+There are similar CLEAR commands for the other filters:-
+
+ clear/announce
+ clear/wcy
+ clear/wwv
+
+ADVANCED USERS:-
+
+Once you are happy with the results you get, you may like to experiment.
+
+my example that filters hf/cw spots and accepts vhf/uhf spots from EU
+can be written with a mixed filter, eg:
+
+ rej/spot on hf/cw
+ acc/spot on 0/30000
+ acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)
+
+each filter slot actually has a 'reject' slot and an 'accept'
+slot. The reject slot is executed BEFORE the accept slot.
+
+It was mentioned earlier that after a reject test that doesn't match,
+the default for following tests is 'accept', the reverse is true for
+'accept'. In the example what happens is that the reject is executed
+first, any non hf/cw spot is passed to the accept line, which lets
+thru everything else on HF.
+
+The next filter line lets through just VHF/UHF spots from EU.
+
<sect1>forward/latlong (8)
<P>
This uses the subject field, so any messages that have exactly the same subject
will be deleted. Beware!
+<sect1>kill/expunge (6)
+
+<P>
+<tt>
+<bf>kill/expunge <msgno> [<msgno>..]</bf>Expunge a message
+</tt>
+
+<P>
+Deleting a message using the normal KILL commands only marks that message
+for deletion. The actual deletion only happens later (usually two days later).
+
+The KILL EXPUNGE command causes the message to be truly deleted more or less
+immediately.
+
+It otherwise is used in the same way as the KILL command.
+
+
<sect1>links (0)
<P>
do this if you change this file whilst the cluster is running in order for the
changes to take effect.
-
-<sect1>load/baddx (9)
-
-<P>
-<tt>
-<bf>load/baddx</bf> Reload the bad DX table
-</tt>
-
-<P>
-Reload the /spider/data/baddx.pl file if you have changed it manually whilst
-the cluster is running. This table contains the DX Calls that, if spotted,
-will not be passed on. FR0G and TEST are classic examples.
-
<sect1>load/badmsg (9)
<P>
<P>
<tt>
-<bf>load/badwords</bf> Reload the badwords file
+<bf>load/badwords</bf> Reload the bad words table
</tt>
<P>
Use with extreme care. This command may well be superceded by FILTERing.
+<sect1>set/badword (8)
+
+<P>
+<tt>
+<bf>set/badword <word></bf> Stop things with this word being propogated
+</tt>
+
+<P>
+Setting a word as a 'badword' will prevent things like spots,
+announces or talks with this word in the the text part from going any
+further. They will not be displayed and they will not be sent onto
+other nodes.
+
+The word must be written in full, no wild cards are allowed eg:-
+
+ set/badword annihilate annihilated annihilation
+
+will stop anything with these words in the text.
+
+ unset/badword annihilated
+
+will allow text with this word again.
+
+
<sect1>set/beep (0)
<P>
YOU DO NOT NEED TO USE THIS COMMAND IF YOU ARE CONNECTED VIA AX25.
+<sect1>set/email (0)
+
+<P>
+<tt>
+<bf>set/email <email_address></bf> Set email address(es) and forward your personals
+</tt>
+
+<P>
+If any personal messages come in for your callsign then you can use
+these commands to control whether they are forwarded onto your email
+address. To enable the forwarding do something like:-
+
+ SET/EMAIL mike.tubby@somewhere.com
+
+You can have more than one email address (each one separated by a space).
+Emails are forwarded to all the email addresses you specify.
+
+You can disable forwarding by:-
+
+ UNSET/EMAIL
+
<sect1>set/here (0)
<P>
The setting is stored in your user profile.
+<sect1>set/password (0)
+
+<P>
+<tt>
+<bf>set/password</bf> Set your own password
+</tt>
+
+<P>
+This command only works for a 'telnet' user (currently). It will
+only work if you have a password already set. This initial password
+can only be set by the sysop.
+
+When you execute this command it will ask you for your old password,
+then ask you to type in your new password twice (to make sure you
+get it right). You may or may not see the data echoed on the screen
+as you type, depending on the type of telnet client you have.
<sect1>set/password (9)
<P>
The password for a user can only be set by a full sysop. The string
-can contain any characters but any spaces are removed (you can type in
-spaces - but they won't appear in the password). You can see the
-result with STAT/USER. The password is the usual 30 character baycom
-type password.
+can contain any characters.
+
+The way this field is used depends on context. If it is being used in
+the SYSOP command context then you are offered 5 random numbers and you
+have to supply the corresponding letters. This is now mainly for ax25
+connections.
+
+If it is being used on incoming telnet connections then, if a password
+is set or the:
+
+ set/var $main::passwdreq = 1
+
+command is executed in the startup script, then a password prompt is
+given after the normal 'login: ' prompt.
+
+The command "unset/password" is provided to allow a sysop to remove a
+users password completely in case a user forgets or loses their password.
<sect1>set/pinginterval (9)
<P>
-<tt>
-<bf>set/pinginterval <time> <node call></bf> Set the ping time
+<tt><bf>set/pinginterval <time> <node call></bf> Set the ping time
to neighbouring nodes
</tt>
set/qth East Dereham, Norfolk
</verb></tscreen>
+<sect1>set/register (9)
+
+<P>
+<tt>
+<bf>set/register <call></bf> Mark a user as registered
+</tt>
+
+<P>
+Registration is a concept that you can switch on by executing the
+
+ set/var $main::regreq = 1
+
+command (usually in your startup file)
+
+If a user is NOT registered then, firstly, instead of the normal
+motd file (/spider/data/motd) being sent to the user at startup, the
+user is sent the motd_nor file instead. Secondly, the non registered
+user only has READ-ONLY access to the node. The non-registered user
+cannot use DX, ANN etc.
+
+The only exception to this is that a non-registered user can TALK or
+SEND messages to the sysop.
+
+To unset a user use the 'unset/register' command
+
<sect1>set/talk (0)
<P>
Display all the bad spotter's callsigns in the system, see SET/BADSPOTTER
for more information.
+<sect1>show/badword (1)
+
+<P>
+<tt>
+<bf>show/badword</bf> Show all the bad words in the system
+</tt>
+
+<P>
+Display all the bad words in the system, see SET/BADWORD
+for more information.
+
<sect1>show/configuration (0)
<P>
SH/DXCC W on 20m info iota
</verb></tscreen>
+<sect1>sh/dxstats (0)
+
+<P>
+<tt>
+<bf>sh/dxstats</bf> Show the DX Statistics for last 31 days
+</tt>
+
+<P>
+Show the total DX spots for the last 31 days
+
+
<sect1>show/files (0)
<P>
<P>
A sysop can look at any filters that have been set.
+<sect1>show/hfstats (0)
+
+<P>
+<tt>
+<bf>show/hfstats</bf> Show the HF DX Statistics for last 31 days
+</tt>
+
+<P>
+Show the HF DX spots breakdown by band for the last 31 days
+
+<sect1>show/hftable (0)
+
+<P>
+<tt>
+<bf>show/hftable</bf> Show the HF DX Spotter Table for your country
+</tt>
+
+<P>
+Show the HF DX Spotter table for your country for the last 31 days
+
<sect1>show/hops (8)
<P>
indicating that you will have weak, fading circuits on top band and
80m but usable signals on 40m (about S3).
-inputing:-
+inputting:-
<tscreen><verb>
SH/MUF W 24
should be noted that the figures will probably not be very useful, nor
terrible accurate, but it is included for completeness.
+<sect1>show/newconfiguration (0)
+
+<P>
+<tt>
+<bf>show/newconfiguration [<node>]</bf> Show all the nodes and users visible
+</tt>
+
+<P>
+This command allows you to see all the users that can be seen
+and the nodes to which they are connected.
+
+This command produces essentially the same information as
+SHOW/CONFIGURATION except that it shows all the duplication of
+any routes that might be present It also uses a different format
+which may not take up quite as much space if you don't have any
+loops.
+
+BE WARNED: the list that is returned can be VERY long
+
+<sect1>show/newconfiguration/node (0)
+
+<P>
+<tt>
+<bf>show/newconfiguration/node</bf> Show all the nodes connected locally
+</tt>
+
+<P>
+Show all the nodes connected to this node in the new format.
+
<sect1>show/node (1)
<P>
and returns any information available for that callsign. This service
is provided for users of this software by http://www.qrz.com
+<sect1>show/registered (9)
+
+<P>
+<tt>
+<bf>show/registered [<prefix>[</bf> Show the registered users
+</tt>
+
<sect1>show/route (0)
<P>
then it will show UTC and UTC + the local offset (not including DST) at
the prefixes or callsigns that you specify.
+<sect1>show/vhfstats (0)
+
+<P>
+<tt>
+<bf>show/vhfstats</bf> Show the VHF DX Statistics for last 31 days
+</tt>
+
+<P>
+Show the VHF DX spots breakdown by band for the last 31 days
+
+<sect1>show/vhftable (0)
+
+<P>
+<tt>
+<bf>show/vhftable</bf> Show the VHF DX Spotter Table for your country
+</tt>
+
+<P>
+Show the VHF DX Spotter table for your country for the last 31 days
+
<sect1>show/wcy (0)
<P>
projects / spider.git / blobdiff