+++ /dev/null
- The DXSpider Administration Manual v1.50
- Ian Maude, G0VGS, (g0vgs@gb7mbc.net), and Charlie Carroll,
- K1XX, (k1xx@ptcnh.net)
- February 2003 revision 0.3
-
- A reference for SysOps of the DXSpider DXCluster program.
- ______________________________________________________________________
-
- Table of Contents
-
-
-
- 1. Routing and Filtering
- 1.1 Introduction
- 1.2 Route Filters
- 1.3 The node_default filter
- 1.4 General route filtering
- 1.5 General filter rules
- 1.6 Types of filter
- 1.7 Filter options
- 1.8 Default filters
- 1.9 Advanced filtering
- 1.10 Basic hop control
- 1.11 Hop Control on Specific Nodes
- 1.12 Isolating networks
-
- 2. Other filters
- 2.1 Filtering Mail
- 2.2 Filtering words from text fields in Announce, Talk and DX spots
- 2.3 Stopping (possibly bad) DX Spots from Nodes or Spotters
-
- 3. Mail
- 3.1 Personal mail
- 3.2 Bulletin mail
- 3.3 Forward.pl
- 3.4 The msg command
- 3.5 Message status
- 3.6 Filtering mail
- 3.7 Distribution lists
- 3.8 BBS interface
-
- 4. Scripts
- 5. Databases
- 5.1 Creating databases
- 5.2 Importing databases
- 5.3 Checking available databases
- 5.4 Looking up databases
- 5.5 Removing databases
-
- 6. Information, files and useful programs
- 6.1 MOTD
- 6.2 MOTD_NOR
- 6.3 Downtime message
- 6.4 Other text messages
- 6.5 The Aliases file
- 6.6 Console.pl
- 6.7 Updating kepler data
- 6.8 The QRZ callbook
- 6.9 Connecting logging programs
-
- 7. Java Web applet
- 8. Web based statistics
- 9. Security
- 9.1 Registration
- 9.2 Passwords
-
- 10. CVS
- 10.1 CVS from a Linux platform
- 10.2 CVS from a Windows platform
-
- 11. The DXSpider command set
- 11.1 accept/announce (0)
- 11.2 accept/announce (extended for sysops) (8)
- 11.3 accept/route (8)
- 11.4 accept/spots (0)
- 11.5 accept/spots (extended for sysops) (8)
- 11.6 accept/wcy (0)
- 11.7 accept/wcy (extended for sysops) (8)
- 11.8 accept/wwv (0)
- 11.9 accept/wwv (extended for sysops) (8)
- 11.10 announce (0)
- 11.11 announce full (0)
- 11.12 announce sysop (5)
- 11.13 apropos (0)
- 11.14 bye (0)
- 11.15 catchup (5)
- 11.16 clear/announce (8)
- 11.17 clear/route (8)
- 11.18 clear/spots (0)
- 11.19 clear/spots (extended for sysops) (8)
- 11.20 clear/wcy (0)
- 11.21 clear/wcy (extended for sysops) (8)
- 11.22 clear/wwv (0)
- 11.23 clear/wwv (extended for sysops) (8)
- 11.24 connect (5)
- 11.25 dbavail (0)
- 11.26 dbcreate (9)
- 11.27 dbimport (9)
- 11.28 dbremove (9)
- 11.29 dbshow (0)
- 11.30 debug (9)
- 11.31 delete/user (9)
- 11.32 demonstrate (9)
- 11.33 directory (0)
- 11.34 directory (extended for sysops) (5)
- 11.35 disconnect (8)
- 11.36 dx (0)
- 11.37 export (9)
- 11.38 export_users (9)
- 11.39 filtering (0)
- 11.40 forward/latlong (8)
- 11.41 forward/opername (1)
- 11.42 help (0)
- 11.43 init (5)
- 11.44 kill (0)
- 11.45 kill (5)
- 11.46 kill full (5)
- 11.47 kill/expunge (6)
- 11.48 links (0)
- 11.49 load/aliases (9)
- 11.50 load/badmsg (9)
- 11.51 load/badwords (9)
- 11.52 load/bands (9)
- 11.53 load/cmd_cache (9)
- 11.54 load/forward (9)
- 11.55 load/messages (9)
- 11.56 load/prefixes (9)
- 11.57 merge (5)
- 11.58 msg (9)
- 11.59 pc (8)
- 11.60 ping (1)
- 11.61 rcmd (1)
- 11.62 read (0)
- 11.63 read (extended for sysops) (5)
- 11.64 reject/announce
- 11.65 reject/announce (extended for sysops) (8)
- 11.66 reject/route (8)
- 11.67 reject/spots (0)
- 11.68 reject/spots (extended for sysops) (8)
- 11.69 reject/wcy (0)
- 11.70 reject/wcy (extended for sysops) (8)
- 11.71 reject/wwv (0)
- 11.72 reject/wwv (extended for sysops) (8)
- 11.73 reply (0)
- 11.74 send (0)
- 11.75 set/address (0)
- 11.76 set/announce (0)
- 11.77 set/arcluster (5)
- 11.78 set/baddx (8)
- 11.79 set/badnode (6)
- 11.80 set/badspotter (8)
- 11.81 set/badword (8)
- 11.82 set/beep (0)
- 11.83 set/bbs (5)
- 11.84 set/clx (5)
- 11.85 set/debug (9)
- 11.86 set/dx (0)
- 11.87 set/dxgrid (0)
- 11.88 set/dxnet (5)
- 11.89 set/echo (0)
- 11.90 set/email (0)
- 11.91 set/here (0)
- 11.92 set/homenode (0)
- 11.93 set/hops (8)
- 11.94 set/isolate (9)
- 11.95 set/language (0)
- 11.96 set/location (0)
- 11.97 set/sys_location (9)
- 11.98 set/logininfo (0)
- 11.99 set/lockout (9)
- 11.100 set/name (0)
- 11.101 set/node (9)
- 11.102 set/obscount (9)
- 11.103 set/page (0)
- 11.104 set/password (0)
- 11.105 set/password (9)
- 11.106 set/pinginterval (9)
- 11.107 set/privilege (9)
- 11.108 set/spider (5)
- 11.109 set/sys_qra (9)
- 11.110 set/qra (0)
- 11.111 set/qth (0)
- 11.112 set/register (9)
- 11.113 set/talk (0)
- 11.114 set/wcy (0)
- 11.115 set/wwv (0)
- 11.116 set/wx (0)
- 11.117 show/baddx (1)
- 11.118 show/badnode (6)
- 11.119 show/badspotter (1)
- 11.120 show/badword (1)
- 11.121 show/configuration (0)
- 11.122 show/configuration/node (0)
- 11.123 show/connect (1)
- 11.124 show/date (0)
- 11.125 show/debug (9)
- 11.126 show/dx (0)
- 11.127 show/dxcc (0)
- 11.128 sh/dxstats (0)
- 11.129 show/files (0)
- 11.130 show/filter (0)
- 11.131 show/filter (extended for sysops) (5)
- 11.132 show/hfstats (0)
- 11.133 show/hftable (0)
- 11.134 show/hops (8)
- 11.135 show/isolate (1)
- 11.136 show/lockout (9)
- 11.137 show/log (8)
- 11.138 show/moon (0)
- 11.139 show/muf (0)
- 11.140 show/newconfiguration (0)
- 11.141 show/newconfiguration/node (0)
- 11.142 show/node (1)
- 11.143 show/prefix (0)
- 11.144 show/program (5)
- 11.145 show/qra (0)
- 11.146 show/qrz (0)
- 11.147 show/registered (9)
- 11.148 show/route (0)
- 11.149 show/satellite (0)
- 11.150 show/sun (0)
- 11.151 show/time (0)
- 11.152 show/vhfstats (0)
- 11.153 show/vhftable (0)
- 11.154 show/wcy (0)
- 11.155 show/wwv (0)
- 11.156 shutdown (5)
- 11.157 spoof (9)
- 11.158 stat/db (5)
- 11.159 stat/channel (5)
- 11.160 stat/msg (5)
- 11.161 stat/route_node (5)
- 11.162 stat/route_user (5)
- 11.163 stat/user (5)
- 11.164 sysop (0)
- 11.165 talk (0)
- 11.166 type (0)
- 11.167 who (0)
- 11.168 wx (0)
- 11.169 wx (enhanced for sysops) (5)
-
-
- ______________________________________________________________________
-
- 1. Routing and Filtering
-
- 1.1. Introduction
-
- 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.
-
-
- In fact DXSpider has had a simple system for some time which is called
- isolation. This is similar to what in other systems such as clx, is
- called passive mode. A more detailed explanation of isolation is given
- further below. This system is still available and, for simple
- networks, is probably all that you need.
-
-
- The new functionality introduced in version 1.48 allows filtering the
- node and user protocol frames on a "per interface" basis. We call this
- route filtering. This is used instead of isolation.
-
-
- What this really means is that you can control more or less completely
- which user and node management PC protocol frames pass to each of your
- partner nodes. You can also limit what comes into your node from your
- partners. It is even possible to control the settings that your
- partner node has for the routing information that it sends to you
- (using the rcmd command).
-
-
- 1.2. Route Filters
-
- Initially when route filters were being tested we generated a
- "default" filter. Unfortunately it quickly became apparent that this
- might suit the UK cluster network but didn't really fit anybody else.
- However using a default filter is an appropriate thing to do. How, is
- explained further on.
-
-
- The first thing that you must do is determine whether you need to use
- route filtering at all. If you are a "normal" node with two or three
- partners and you arranged in an "official" non-looping tree type
- network, then you do not need to do route filtering and you will feel
- a lot better for not getting involved. If you are successfully using
- isolation then you also probably don't need to use route filtering.
-
-
- To put it simply, you should not mix Isolation and Route Filtering.
- It will work, of sorts, but you will not get the expected results. If
- you are using Isolation sucessfully at the moment, do not get involved
- in Route Filtering unless you have a good supply of aspirin! Once you
- have started down the road of Route Filtering, do not use Isolation
- either. Use one or the other, not both.
-
-
- 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.
-
-
- 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.
-
-
-
- Anyway, without further discouragement, let me start the process of
- explanation.
-
-
- 1.3. The node_default filter
-
- 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.
-
-
-
- The generic commands are:-
-
-
-
- reject/route node_default <filter_option>
-
- or
-
- accept/route node_default <filter_option>
-
-
-
- where filter_option is one of the following ...
-
-
-
- call <prefixes>
- call_dxcc <numbers>
- call_itu <numbers>
- call_zone <numbers>
- channel <prefixes>
- channel_dxcc <numbers>
- channel_itu <numbers>
- channel_zone <numbers>
-
-
-
- Please be careful if you alter this setting, it will affect ALL your
- links! Remember, this is a default filter for node connections, not a
- per link default.
-
-
- 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:-
-
-
-
- acc/route node_default call_dxcc 61,38
- acc/route node_default call gb7djk
-
-
-
- GB7DJK uses the first of these. The DXCC countries can be obtained
- from the show/prefix command.
-
-
- The example filters shown control output TO all your partner nodes
- unless they have a specific filter applied to them (see next section).
-
-
- It is also possible to control the incoming routing information that
- you are prepared to accept FROM 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:
-
-
-
- rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38
-
-
-
- What this does is accept node and user information for our national
- network from nodes that are in our national network, but rejects such
- information from anyone else. Although it doesn't explicitly say so,
- by implication, any other node information (not from the UK and Eire)
- is accepted.
-
-
- As I imagine it will take a little while to get one's head around all
- of this you can study the effect of any rules that you try by watching
- the debug output after having done:-
-
-
-
- set/debug filter
-
-
-
- After you have got tired of that, to put it back the way it was:-
-
-
-
- unset/debug filter
-
-
-
- 1.4. General route filtering
-
- Exactly the same rules apply for general route filtering. You would
- use either an accept filter or a reject filter like this ...
-
-
-
- reject/route <node_call> <filter_option>
-
- or
-
- accept/route <node_call> <filter_option>
-
-
-
- Here are some examples of route filters ...
-
-
-
- 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)
-
-
-
- In practice you will either be opening the default filter out for a
- partner by defining a specific filter for that callsign:-
-
-
-
- acc/route gb7baa all
- acc/route gb7baa input all
-
-
-
- or restricting it quite a lot, in fact making it very nearly like an
- isolated node, like this:-
-
-
-
- acc/route pi4ehv-8 call gb7djk
- rej/route pi4ehv-8 input call_dxcc 61,38
-
-
-
- This last example takes everything except UK and Eire from PI4EHV-8
- but only sends him my local configuration (just a PC19 for GB7DJK and
- PC16s for my local users).
-
-
- It is possible to write much more complex rules, there are up to 10
- accept/reject pairs per callsign per filter. For more information see
- the next section.
-
-
-
- 1.5. General filter rules
-
- 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.
-
-
- There are 3 basic commands involved in setting and manipulating
- filters. These are accept, reject and clear. 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.
-
-
- 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.
- They are ...
-
-
-
- clear/spots 1
- clear/spots all
-
-
-
- There is clear/xxxx command for each type of filter.
-
-
- and you can check that your filters have worked by the command ...
-
-
-
- show/filter
-
-
-
- For now we are going to use spots for the examples, but you can apply
- the same principles to all types of filter.
-
-
- 1.6. Types of filter
-
- There are two main types of filter, accept or reject. 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)
-
-
- 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
- accept filter ...
-
-
-
- accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
- then you will ONLY get VHF spots from or to CQ zones 14, 15 and 16.
-
-
- If you set a reject filter like this ...
-
-
-
- reject/spots on hf/cw
-
-
-
- Then you will get everything EXCEPT 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 ...
-
-
-
- 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 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!
-
-
- You can arrange your filter lines into logical units, either for your
- own understanding or simply convenience. Here is an example ...
-
-
-
- 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 and also rejects any spots
- on VHF which don't either originate or spot someone in Europe.
-
-
- 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.
-
-
- 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 APART 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 ...
-
-
-
- (on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16
-
-
-
- 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 ...
-
-
-
- reject/spots 1 on hf/ssb
-
- would redefine our earlier example, or
-
-
-
- clear/spots 1
-
-
-
- To remove all the filter lines in the spot filter ...
-
-
-
- clear/spots all
-
-
-
- 1.7. Filter options
-
- You can filter in several different ways. The options are listed in
- the various helpfiles for accept, reject and filter.
-
-
- 1.8. Default filters
-
- 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 ...
-
-
-
- accept/spot node_default by_zone 14,15,16,20,33
- set/hops node_default spot 50
-
-
-
- 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.
-
-
- 1.9. Advanced filtering
-
- Once you are happy with the results you get, you may like to
- experiment.
-
-
- The previous example that filters hf/cw spots and accepts vhf/uhf
- spots from EU can be written with a mixed filter, for example ...
-
-
-
- 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)
-
- 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 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. 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
- through everything else on HF. The next filter line lets through just
- VHF/UHF spots from EU.
-
-
- 1.10. Basic hop control
-
- 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 ...
-
-
-
- #
- # hop table construction
- #
-
- package DXProt;
-
- # default hopcount to use
- $def_hopcount = 5;
-
- # some variable hop counts based on message type
- %hopcount =
- (
- 11 => 10,
- 16 => 10,
- 17 => 10,
- 19 => 10,
- 21 => 10,
- );
-
-
- # the per node hop control thingy
-
-
- %nodehops =
- (
- GB7ADX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-
- GB7UDX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
- GB7BAA => {
- 11 => 5,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
- );
-
-
-
- Each set of hops is contained within a pair of curly braces and
- contains a series of PC frame types. PC11 for example is a DX spot.
- The figures here are not exhaustive but should give you a good idea of
- how the file works.
-
-
- SHould any of the nodecalls include an ssid, it is important to wrap
- the whole call in single quotes, like this ...
-
-
-
- 'DB0FHF-15' => {
- 11 => 5,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-
-
-
- If you do not do this, you will get errors and the file will not work
- as expected.
-
-
- You can alter this file at any time, including whilst the cluster is
- running. If you alter the file during runtime, the command load/hops
- will bring your changes into effect.
-
-
- 1.11. Hop Control on Specific Nodes
-
- You can set a callsign specific hop count for any of the standard
- filter options so:-
-
-
-
- set/hops gb7djk spot 4
- set/hops node_default route 10
- set/hops gb7baa wcy 5
-
-
-
- all work on their specific area of the protocol.
-
-
- The set/hops command overrides any hops that you have set otherwise.
-
-
- You can show what hops have been set using the show/hops command.
-
-
- 1.12. Isolating networks
-
- It is possible to isolate networks from each other on a "gateway" node
- using the set/isolate <node_call> command.
-
-
- 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.
-
-
- 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 acc/spot >call< all filter to override the isolate.
-
-
- 2. Other filters
-
- 2.1. Filtering Mail
-
- 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 ....
-
-
-
- # 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 = (
- );
-
-
-
- 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.
-
-
-
- 2.2. Filtering words from text fields in Announce, Talk and DX spots
-
- From version 1.48 onwards the interface to this has changed. You can
- now use the commands set/badword to add words that you are not
- prepared to see on the cluster, unset/badword to allow that word again
- and show/badword to list the words that you have set.
-
-
- If you have a previous /spider/data/badwords, 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.
-
-
- 2.3. Stopping (possibly bad) DX Spots from Nodes or Spotters
-
-
- There are a number of commands that control whether a spot progresses
- any further by regarding it as "bad" in some way.
-
-
- 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.
-
-
- There are a set of commands which allow the sysop to control whether a
- spot continues:-
-
-
-
- set/baddx
- set/badspotter
- set/badnode
-
-
-
- These work in the same as the set/badword 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:
-
-
-
- set/badnode gb7djk gb7dxc
-
-
-
- a bad spotter:
-
-
-
- set/badspotter b0mb p1rat nocall
-
-
-
- and some bad dx:
-
-
-
- set/baddx video wsjt
-
-
-
- You can remove a word using the appropriate unset command
- (unset/baddx, unset/badspotter, unset/badnode) or list them using one
- of show/baddx, show/badspotter and show/badnode.
-
-
-
- 3. Mail
-
- 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 msg command.
-
-
- 3.1. Personal mail
-
- Personal mail is sent using the sp command. This is actually the
- default method of sending mail and so a simple s for send will do. A
- full list of the send commands and options is in the command set
- section, so I will not duplicate them here.
-
-
- 3.2. Bulletin mail
-
- Bulletin mail is sent by using the sb command. This is one of the
- most common mistakes users make when sending mail. They send a
- bulletin mail with s or sp instead of sb and of course the message
- never leaves the cluster. This can be rectified by the sysop by using
- the msg command.
-
-
- Bulletin addresses can be set using the Forward.pl file.
-
-
- 3.3. Forward.pl
-
- 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 ...
-
-
-
- #
- # 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 = (
- );
-
-
-
- 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.
-
-
- To force the cluster to reread the file use load/forward
-
-
- NB: If a user tries to send mail to a bulletin address that does not
- exist in this file, they will get an error.
-
-
- 3.4. The msg command
-
- The msg 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 ...
-
-
-
- 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
-
-
-
- These commands are simply typed from within the cluster as the sysop
- user.
-
-
- 3.5. Message status
-
- You can check on a message from within the cluster by using the
- command stat/msg. 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 ...
-
-
-
- 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 >
-
-
-
- 3.6. Filtering mail
-
- This is described in the section on Other filters so I will not
- duplicate it here.
-
-
- 3.7. Distribution lists
-
- 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 distro. You put
- any distibution lists in here. For example, here is a file called
- SYSOP.pl that caters for the UK sysops.
-
-
- qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX
- GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH
- GB7DXK GB7DXI GB7DXS)
-
-
-
- Any mail sent to "sysop" would only be sent to the callsigns in this
- list.
-
-
- 3.8. BBS interface
-
- 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.
-
-
- 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.
-
-
- 4. Scripts
-
- From 1.48 onwards it will become increasingly possible to control
- DXSpider's operation with scripts of various kinds.
-
-
- 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.
-
-
-
- #
- # 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
- #
-
-
-
- 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 sh/dx 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.
-
-
- The other 2 options are dealt with more fully in the security section.
-
-
- 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.
-
-
-
- #
- # G0FYD
- #
- blank +
- sh/wwv 3
- blank +
- sh/dx
- blank +
- t g0jhc You abt?
- blank +
-
-
-
- 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.
-
-
- 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.
-
-
- Thirdly, there are 2 default scripts for users and nodes who do not
- have a specifically defined script. These are user_default and
- node_default
-
-
- 5. Databases
-
- 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.
-
-
- 5.1. Creating databases
-
- Creating a database could not be more simple. All the commands are
- sent from the cluster prompt as the sysop user.
-
- To create a database you use the command dbcreate. It can be used in
- 3 different ways like so ..
-
-
-
- dbcreate <name>
-
-
- 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.
-
-
-
- dbcreate <name> chain <name> [<name>...]
-
-
-
- This creates a chained database entry. The first database will be
- scanned, then the second, the third etc...
-
-
-
- dbcreate <name> remote <name>
-
-
-
- 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...
-
-
-
- dbcreate buckmaster remote gb7dxc
-
-
-
- Remote databases cannot be chained, however, the last database in a
- chain can be a remote database.
-
-
- 5.2. Importing databases
-
- 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 ...
-
-
-
- dbimport oblast /tmp/OBLAST.FUL
-
-
-
- This will update the existing local oblast database or create it if it
- does not exist.
-
-
- 5.3. Checking available databases
-
- Once a database is created, you will want to check that it has been
- added. To do this use the dbavail command. This will output the
- available databases. For example ...
-
-
-
- dbavail
- DB Name Location Chain
- qsl Local
- buck GB7ADX
- hftest GB7DXM
- G0VGS de GB7MBC 3-Feb-2001 1925Z >
-
-
-
- 5.4. Looking up databases
-
- To look for information in a defined database, simply use the dbshow
- command, for example ...
-
-
-
- dbshow buckmaster G0YLM
-
-
-
- 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
- show command like this ...
-
-
-
- Now you can simply use show/buckmaster or an abreviation.
-
-
- 5.5. Removing databases
-
- To delete an existing database you use the dbremove command. For
- example ...
-
-
-
- dbremove oblast
-
-
-
- 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.
-
-
- 6. Information, files and useful programs
-
- 6.1. MOTD
-
- 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.
- 6.2. MOTD_NOR
-
- 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.
-
-
- 6.3. Downtime message
-
- 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.
-
-
- 6.4. Other text messages
-
- 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
- packclus. Under this directory you can create files called news or
- newuser for example. In fact you can create files with any names you
- like. These can be listed by the user with the command ....
-
-
-
- show/files
-
-
-
- They can be read by the user by typing the command ....
-
-
-
- type news
-
-
-
- If the file they want to read is called news. You could also set an
- alias for this in the Alias file to allow them just to type news
-
-
- 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 bulletin. Now copy any OPDX or similar
- bulletins into it. These can be listed by the user in the same way as
- above using the show/files command with an extension for the bulletin
- directory you have just created, like this ....
-
-
-
- show/files bulletin
-
-
-
- An example would look like this ....
-
- sh/files
- bulletin DIR 20-Dec-1999 1715Z news 1602 14-Dec-1999 1330Z
-
-
-
- You can see that in the files area (basically the packclus directory)
- there is a file called news and a directory called bulletin. You can
- also see that dates they were created. In the case of the file news,
- 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 news you would simply issue the command ....
-
-
-
- type news
-
-
-
- To look what is in the bulletin directory you issue the command ....
-
-
-
- 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) >
-
-
-
- You can now read any file in this directory using the type command,
- like this ....
-
-
-
- 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) >
-
-
-
- The page length will of course depend on what you have it set to!
-
-
- 6.5. The Aliases file
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
-
- #
- # 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',
- ],
- )
-
-
-
- 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.
-
-
- 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 with similar commands.
-
-
- 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 type news. The alias allows them to simply
- type news to get the info. Second is an alias for the show/qrz
- command so that those users used to the original show/buck 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 show/hftest instead of
- having to use the command dbshow hftest which is not as intuitive.
-
-
- This file is just an example and you should edit it to your own
- requirements. Once created, simply issue the command load/alias at
- the cluster prompt as the sysop user and the aliases should be
- available.
-
-
-
- 6.6. Console.pl
-
- 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.
-
-
- To edit the colours, copy /spider/perl/Console.pl to /spider/local and
- edit the file with your favourite editor.
-
-
- 6.7. Updating kepler data
-
- 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 export command from the cluster prompt as
- the sysop. For example ...
-
-
-
- export 5467 /spider/perl/keps.in
-
-
-
- would export message number 5467 as a file called keps.in in the
- /spider/perl directory.
-
-
- Now login to a VT as sysop and cd /spider/perl. There is a command in
- the perl directory called convkeps.pl. All we need to do now is
- convert the file like so ...
-
-
-
- ./convkeps.pl keps.in
-
-
-
- Now go back to the cluster and issue the command ...
-
-
-
- load/keps
-
-
-
- That is it! the kepler data has been updated.
-
-
- 6.8. The QRZ callbook
-
- The command sh/qrz 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 qrz.com for allowing this access.
-
-
- 6.9. Connecting logging programs
-
- 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 agetty.
-
-
- 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.
-
-
-
- c4:2345:respawn:/sbin/agetty -L 9600 ttyS1
-
-
-
- Add this after the standard runlevel lines in /etc/inittab. The above
- line works on ttyS1 (com2). Now as root, issue the command telinit q
- 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.
-
-
- 7. Java Web applet
-
- In the spider tree will be a directory spider-web. 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.
-
-
- 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 ...
-
-
-
- cd /spider/spider-web
- rm *.class
- /usr/bin/javac spiderclient.java
-
-
-
- I have used /usr/bin/javac as an example, your path to javac may be
- different.
-
-
- 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" ;
-
-
- 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
-
-
-
- 8. Web based statistics
-
- From version 1.50, you can use the freeware software MRTG to produce
- really nice graphical statistics on your web site. For an example try
- http://www.gb7mbc.net/mrtg/stats.html.
-
-
- The following should help you get it all working.
-
-
- First you need to download the latest version of MRTG from
- http://people.ee.ethz.ch/~oetiker/webtools/mrtg/. You will also need
- the following files..
-
-
-
- libpng-1.0.14.tar.gz
- zlib-1.1.4.tar.gz
- gd-1.8.3.tar.gz
-
-
-
- Login to your machine as the root user, put all the downloaded files
- in /usr/local/src/ (or wherever you prefer) and untar and compile
- them. All the information to compile and install these sources come
- with them. After compilation and installation, you will find MRTG in
- /usr/local/mrtg-2.
-
-
- Now copy all the files in /usr/local/src/mrtg-2.9.22/images/ to
- /spider/html/mrtg/
-
-
- You now need to make 2 symbolic links like below...
-
-
-
- ln -s /usr/local/mrtg-2/bin/mrtg /usr/bin/mrtg
- ln -s /usr/local/mrtg-2/lib/mrtg2 /usr/lib/mrtg2
-
-
-
- Now login to the cluster with your sysop callsign and run the command
- "mrtg all".
-
-
- Now you are nearly there! Login as the sysop user and change to the
- /spider/html/mrtg/ directory. Now run the command indexmaker as shown
- below...
-
-
-
- indexmaker --output stats.html --columns=1 --title "MRTG statistics for GB7DJK" ../../mrtg/mrtg.cfg
-
-
-
- Changing the callsign for your own cluster callsign of course!
-
-
- And finally you need to login as the root user and create one last
- symbolic link. Where this points will depend on where your html
- documents are kept. For RedHat systems you use...
-
-
-
- ln -s /home/sysop/spider/html/mrtg /home/httpd/html/mrtg
-
-
-
- and for SuSE systems...
-
-
-
- ln -s /home/sysop/spider/html/mrtg /usr/local/httpd/htdocs/mrtg
-
-
-
- If you now point your browser to your website as below it should all
- be happening!
-
-
-
- http://www.xxx.xxx/mrtg/stats.html
-
-
-
- Of course, to get the stats to update, you need to add some
- information in the spider crontab file as below...
-
-
-
- # Update stats for mrtg on website
- 00,05,10,15,20,25,30,35,40,45,50,55 * * * * run_cmd('mrtg all')
-
-
-
- This will update the site every 5 minutes.
-
-
- 9. Security
-
- 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.
-
-
- 9.1. Registration
-
- 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 set/register command,
- like this ...
-
-
-
- set/register g0vgs
-
-
-
- The user g0vgs can now fully use the cluster. In order to enable
- registration, you can issue the command ...
-
- set/var $main::reqreg = 1
-
-
-
- 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.
-
-
- 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.
-
-
- To unregister a user use unset/register and to show the list of
- registered users, use the command show/register.
-
-
- 9.2. Passwords
-
- 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 set/password 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 ...
-
-
-
- set/var $main::passwdreq = 1
-
-
-
- at the cluster prompt. This can also be added to the
- /spider/scripts/startup file as above to make the change permanent.
-
-
- 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.
-
-
- 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 ...
-
-
-
- unset/password g0vgs
- set/password g0vgs new_password
-
-
-
- 10. CVS
-
-
-
- 10.1. CVS from a Linux platform
-
- CVS stands for "Concurrent Versions System" and the CVS for DXSpider
- is held at Sourceforge. This means that it is possible to update your
- DXSpider installation to the latest sources by using a few simple
- commands. A graphical interface to CVS for Windows is explained in
- the next section.
-
-
- 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.
-
-
- I am of course assuming that you have a machine with both DXSpider and
- Internet access running.
-
-
- BEFORE YOU EVEN CONSIDER STARTING WITH THIS MAKE A BACKUP OF YOUR
- ENTIRE SPIDER TREE!!
-
-
- 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 ...
-
-
- First login as the user sysop. Next you need to connect to the CVS
- repository. You do this with the command below ...
-
-
- cvs -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login
-
-
-
- You will get a password prompt. Simply hit return here and your
- machine should return to a normal linux prompt.
-
-
- 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
-
-
- The next step will create a brand new 'spider' directory in your
- current directory.
-
-
- cvs -z3 -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider co spider
-
-
-
- This command is all on one line.
-
-
- 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.
- Now if you are doing a new installation, that's it. Carry on as if
- you have just downloaded and untarred the lastest tarball.
-
-
- If you want to upgrade your current installation then do this ...
-
-
-
- tar cvfz /tmp/s.tgz spider
- cd /
- tar xvfzp /tmp/s.tgz
-
-
-
- This is assuming you downloaded to the /tmp directory of course.
-
-
- 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)
-
-
- 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!
-
-
- Now the magic part! From now on when you want to update, simply
- connect to the Internet and then, as the user sysop ...
-
-
-
- cd /spider
- cvs -z3 update -d
-
-
-
- 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.
-
-
- You will find any changes documented in the /spider/Changes file.
-
-
- 10.2. CVS from a Windows platform
-
- After the initial setup, an update to your DXSpider software is no
- more than a couple of clicks away. This section is intended to
- explain and illustrate the use of the WinCVS application to update
- your DXSpider software. The current stable version of WinCVS is Ver.
- 1.2. You can get this software at:
-
- http://prdownloads.sourceforge.net/cvsgui/WinCvs120.zip
-
- Pick your download mirror and then install WinCVS after the download
- is complete.
-
-
- In this next section I have included a series of links to .jpg files
- to take advantage of the picture and 1000 words equivalency. The .jpg
- files are in the C:\spider\html directory. If someone using a Linux
- system is reading this section from boredom, the files are in
- /home/sysop/spider/html. One aside, a Linux user can also get a copy
- of gcvs and do your updates graphically as opposed to from the command
- line. The following descriptions are almost identical between WinCvs
- and gcvs. The following screen shots have duplicate links, depending
- upon whether you are viewing this information under the Windows or
- Linux operating system.
-
- When WinCVS is installed, running, and you are connected to the
- internet, the initial screen looks like:
-
- initial.jpg
-
- If you want, you can also look at these .jpg files with another viewer
- that might provide some better clarity to the image. On the left is
- the directory tree for your hard disk. Notice that the spider
- directory has a gray highlight.
-
- To start configuring WinCVS, click on Admin at the top of the screen
- and then Preferences. This should get you:
-
- pref-gen.jpg
-
- In the top line for CVSROOT, enter:
-
-
- anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login
-
-
-
- and select
-
-
- "passwd" file on the cvs server
-
-
-
- for Authentication on the General tab.
-
- Next, move to the right to the Ports tab.
-
- pref-ports.jpg
-
- In here, check the box on the second line down for the "pserver" port.
- Enter a port number of 2401.
-
- Finally, go to the WinCvs tab all the way to the right.
-
- pref-wincvs.jpg
-
- Enter Notepad as the viewer to open files. For the HOME folder, put
- "C:\spider" and click OK because the configuration is now complete.
-
- You are now ready to upgrade your copy of DXSpider. Click on the
- greyed Spider folder shown in the directory tree on the left of the
- WinCVS display. Two things should happen. The Spider folder will be
- selected and the greyed-out arrow located just below the word Query in
- the top line will turn to solid green.
-
- For anyone using gcvs under Linux, the green arrow is located on the
- extreme left of the display, under the word File. A gcvs screen looks
- like:
-
- gcvs.jpg
-
- Click on the now green arrow to start the download process. An Update
- Settings box will be displayed to which you can simply say OK.
-
- update-OK.jpg
-
- For future reference, the Update Settings box is the place where you
- can enter information to revert to a prior version of DXSpider.
- Information on reverting to a Before Date is contained in the WinCVS
- manual.
-
- After a short period of time, a series of file names will scroll by in
- the lower pane of the WinCVS window. Eventually you should see
-
-
- *****CVS exited normally with code 0*****
-
-
-
- appear in the lower pane. You're done. The updated files are in
- place ready for you to stop and then restart your DXSpider. After the
- restart, you're running with the latest version of DXSpider.
-
- completed.jpg
-
- To paraphrase from the CVS section... Now the magic part! From now on
- when you want to update, simply connect to the Internet and start
- WinCVS.
-
-
- Click on the greyed-out Spider directory in the left screen
- Click on the green down arrow
- Click OK on the Update Settings dialog box
- Restart your Spider software
-
-
-
- 11. The DXSpider command set
-
- 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
-
-
- 11.1. accept/announce (0)
-
- accept/announce [0-9] <pattern> Set an accept filter line for announce
-
-
- 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:-
-
- 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)
-
-
-
- some examples:-
-
-
-
- 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)
-
-
-
- or
-
-
-
- acc/ann by G,M,2
-
-
-
- This filter would only allow announces that were posted buy UK
- stations. You can use the tag 'all' to accept everything eg:
-
-
-
- acc/ann all
-
-
-
- but this probably for advanced users...
-
-
- 11.2. accept/announce (extended for sysops) (8)
-
- accept/announce <call> [input] [0-9]<pattern> Announce filter sysop
- version
-
-
- This version allows a sysop to set a filter for a callsign as well as
- the default for nodes and users eg:-
-
-
-
- accept/ann by G,M,2
- accept/ann input node_default by G,M,2
- accept/ann user_default by G,M,2
-
-
-
- 11.3. accept/route (8)
-
- accept/route <call> [0-9] <pattern> Set an 'accept' filter line for
- routing
-
-
- Create an 'accept this routing PC Protocol' line for a filter.
-
-
- 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.
-
-
- You can use any of the following things in this line:-
-
-
-
- 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>
-
-
-
- some examples:-
-
-
-
- acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
- acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)
-
-
-
- You can use the tag 'all' to accept everything eg:
-
-
-
- acc/route all
-
-
-
- 11.4. accept/spots (0)
-
- accept/spots [0-9] <pattern> Set an accept filter line for spots
-
-
- Create an 'accept this spot' line for a filter.
-
-
- 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.
-
-
- Please read the following section carefully. Though it looks similar,
- reformatting, corrections, and hopefully clarifications have been
- added.
-
- You can use any of the following things in this line:-
-
-
-
- Filters for the station being spotted:
- call <letters of the prefix, but NOT country inclusive>
- call G --> G1AAA, GJ2BBB, GU3CCC, etc will be spotted
- call K --> K1XX, K1XXX will be spotted
- W1XX, W1XXX will NOT be spotted
- call PA --> PA3EZL will be spotted
- PB2FG will NOT be spotted
-
- call_dxcc <numbers or prefixes>
- call_dxcc G --> G1AAA will be spotted
- GU1AAA will NOT be spotted (different country)
- call_dxcc K --> K1XX, W1XX will be spotted (same country)
- call_dxcc 139 --> PA3EZL and PB2FG will be spotted
-
- call_itu <numbers>
- call_zone <numbers>
-
- Filters for the callsign of the station doing the spotting:
- by <letters of the prefix, but NOT country inclusive>
- by G --> spots from G1AAA, GJ2BBB, GU3CCC, etc will be spotted
- by K --> spots from K1XX, K1XXX will be spotted
- spots from W1XX, W1XXX will NOT be spotted
-
- by_dxcc <numbers or prefixes>
- by_dxcc G --> spots from G1AAA will be spotted
- spots from GU1AAA will NOT be spotted (different
- country)
- by_dxcc K --> spots from K1XX, W1XX will be spotted (same country)
- by_dxcc 139 --> spots from PA3EZL or PB2FG will be spotted
-
- by_itu <numbers>
- by_zone <numbers>
-
- Filters for the callsign of the "node" doing the spotting:
- origin <letters of the prefix, but NOT country inclusive>
- origin K --> spots from a node starting with K will be spotted
- spots from a node starting with KK will NOT be spotted
- spots from a node starting with W will NOT be spotted
-
- Filters for the callsign of the connected node or user (channel) doing the spotting:
- channel <prefixes>
- channel W1HR --> spots from the connected node W1HR will be spotted
- channel K1QX --> spots from the connected user K1QX will be spotted
-
- info <string> eg: iota or qsl
- freq <range> eg: 0/30000 or hf or hf/cw or 6m,4m,2m
- on <range> same as 'freq'
-
-
-
- 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:-
-
-
-
- acc/spot 1 on hf/cw
- acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
- You can use the tag 'all' to accept everything, eg:
-
-
-
- acc/spot 3 all
-
-
-
- but this probably for advanced users...
-
-
- 11.5. accept/spots (extended for sysops) (8)
-
- accept/spots <call> [input] [0-9] <pattern> Spot filter sysop version
-
-
- This version allows a sysop to set a filter for a callsign as well as
- the default for nodes and users eg:-
-
-
-
- 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
-
-
-
- 11.6. accept/wcy (0)
-
- accept/wcy [0-9] <pattern> set an accept WCY filter
-
-
- It is unlikely that you will want to do this, but if you do then you
- can filter on the following fields:-
-
-
-
- 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>
-
-
-
- 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.
-
-
- 11.7. accept/wcy (extended for sysops) (8)
-
- accept/wcy <call> [input] [0-9] <pattern> WCY filter sysop version
-
-
- This version allows a sysop to set a filter for a callsign as well as
- the default for nodes and users eg:-
-
-
-
- accept/wcy node_default all
- set/hops node_default 10
-
-
-
- 11.8. accept/wwv (0)
-
- accept/wwv [0-9] <pattern> Set an accept WWV filter
-
-
- It is unlikely that you will want to do this, but if you do then you
- can filter on the following fields:-
-
-
-
- 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>
-
-
-
- for example
-
-
-
- accept/wwv by_zone 4
-
-
-
- is probably the only useful thing to do (which will only show WWV
- broadcasts by stations in the US).
-
- See HELP FILTER for information.
-
-
-
- 11.9. accept/wwv (extended for sysops) (8)
-
- accept/wwv <call> [input] [0-9] <pattern> WWV filter sysop version
-
-
- This version allows a sysop to set a filter for a callsign as well as
- the default for nodes and users eg:-
-
-
-
- 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
-
-
-
- 11.10. announce (0)
-
- announce <text> Send an announcement to local users
-
-
- 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 set/noannounce command. Any announces made by a
- sysop will override set/noannounce.
-
-
- 11.11. announce full (0)
-
- announce full <text> Send an announcement cluster wide
-
-
- This command will send your announcement across the whole cluster
- network.
-
-
-
- 11.12. announce sysop (5)
-
- announce sysop <text>
-
-
- Send an announcement to Sysops only
-
-
- 11.13. apropos (0)
-
- apropos <string> Search the help database
-
-
- Search the help database for <string> (it isn't case sensitive), and
- print the names of all the commands that may be relevant.
-
-
- 11.14. bye (0)
-
- bye Exit from the cluster
-
-
- This will disconnect you from the cluster
-
-
- 11.15. catchup (5)
-
- catchup <node_call> All|[<msgno> ...] Mark a message as sent
-
-
- 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:-
-
-
-
- catchup GB7DJK all
- catchup GB7DJK 300 301 302 303 500-510
-
-
-
- and to undo what you have just done:-
-
-
-
- uncatchup GB7DJK all
- uncatchup GB7DJK 300 301 302 303 500-510
-
-
-
- which will arrange for them to be forward candidates again.
-
- Order is not important.
-
-
- 11.16. clear/announce (8)
-
- clear/announce <callsign> [input] [0-9|all] Clear an announce filter
- line
-
-
- A sysop can clear an input or normal output filter for a user or the
- node_default or user_default.
-
-
- 11.17. clear/route (8)
-
- clear/route <callsign> [input] [0-9|all] Clear a route filter line
-
-
- 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.
-
-
- 11.18. clear/spots (0)
-
- clear/spots [1|all] Clear a spot filter line
-
-
- This command allows you to clear (remove) a line in a spot filter or
- to remove the whole filter.
- If you have a filter:-
-
-
-
- acc/spot 1 on hf/cw
- acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
- and you say:-
-
-
-
- clear/spot 1
-
-
-
- you will be left with:-
-
-
-
- acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
- If you do:
-
-
-
- clear/spot all
-
-
-
- the filter will be completely removed.
-
-
- 11.19. clear/spots (extended for sysops) (8)
-
- clear/spots <callsign> [input] [0-9|all] Clear a spot filter line
-
-
- A sysop can clear an input or normal output filter for a user or the
- node_default or user_default.
-
-
- 11.20. clear/wcy (0)
-
- clear/wcy [1|all] Clear a WCY filter line
-
-
- 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.
-
-
- 11.21. clear/wcy (extended for sysops) (8)
-
- clear/wcy <callsign> [input] [0-9|all] Clear a WCY filter line
-
-
-
- A sysop can clear an input or normal output filter for a user or the
- node_default or user_default.
-
-
- 11.22. clear/wwv (0)
-
- clear/wwv [1|all] Clear a WWV filter line
-
-
- 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.
-
-
- 11.23. clear/wwv (extended for sysops) (8)
-
- clear/wwv <callsign> [input] [0-9|all] Clear a WWV filter line
-
-
- A sysop can clear an input or normal output filter for a user or the
- node_default or user_default.
-
-
- 11.24. connect (5)
-
- connect <callsign> Start a connection to another DX Cluster
-
-
- 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>.
-
-
- 11.25. dbavail (0)
-
- dbavail Show a list of all the databases in the system
-
-
- The title says it all really, this command lists all the databases
- defined in the system. It is also aliased to SHOW/COMMAND.
-
-
- 11.26. dbcreate (9)
-
- dbcreate <name> Create a database entry
- dbcreate <name> chain <name> [<name>..] Create a chained database
- entry
- dbcreate <name> remote <node> Create a remote database entry
-
-
- 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:-
-
-
-
- 's' => [
- ..
- ..
- '^sh\w*/buc', 'dbshow buckmaster', 'dbshow',
- ..
- ..
- ],
-
-
-
- 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
-
-
- 11.27. dbimport (9)
-
- dbimport <dbname> Import AK1A data into a database
-
-
- 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.
-
-
- 11.28. dbremove (9)
-
- dbremove <dbname> Delete a database
-
- 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.
-
-
- 11.29. dbshow (0)
-
- dbshow <dbname> <key> Display an entry, if it exists, in a database
-
-
- 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:
-
-
-
- SH/BUCK G1TLH
-
-
-
- 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:
-
-
-
- DBSHOW buck G1TLH
-
-
-
- 11.30. debug (9)
-
- debug Set the cluster program into debug mode
-
-
- Executing this command will only have an effect if you are running the
- cluster in debug mode i.e.
-
-
-
- perl -d cluster.pl
-
-
-
- It will interrupt the cluster just after the debug command has
- finished.
-
- 11.31. delete/user (9)
-
- delete/user <callsign> Delete a user from the User Database
-
-
- 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!
-
-
- 11.32. demonstrate (9)
-
- demonstrate <call> <command> Demonstrate a command to another user
-
-
- 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.
-
-
-
- DEMO g7brn sh/dx iota oc209
- DEMO g1tlh set/here
-
-
-
- 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.
-
-
- 11.33. directory (0)
-
- directory List messages
- directory own List your own messages
- directory new List all new messages
- directory to <call> List all messages to <call>
- directory from <call> List all messages from <call>
- directory subject <string> List all messages with <string> in subject
- directory <nn> List last <nn> messages
- directory <from>-<to> List messages <from> message <to> message
-
-
- 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
-
- You can use shell escape characters such as '*' and '?' in the <call>
- fields.
-
- You can combine some of the various directory commands together eg:-
-
-
-
- DIR TO G1TLH 5
- or
- DIR SUBJECT IOTA 200-250
-
-
-
- You can abbreviate all the commands to one letter and use ak1a
- syntax:-
-
-
-
- DIR/T G1* 10
- DIR/S QSL 10-100 5
-
-
-
- 11.34. directory (extended for sysops) (5)
-
- Works just like the user command except that sysops can see ALL
- messages.
-
-
- 11.35. disconnect (8)
-
- disconnect <call> [<call> ...] Disconnect a user or node
-
-
- Disconnect any <call> connected locally
-
-
- 11.36. dx (0)
-
- dx [by <call>] <freq> <call> <remarks> Send a DX spot
-
-
- 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.
-
-
-
- DX FR0G 144.600
- DX 144.600 FR0G
- DX 144600 FR0G
-
-
-
- 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.
-
-
-
- DX FR0G 144600 this is a test
-
-
-
- You can credit someone else by saying:-
-
-
-
- DX by G1TLH FR0G 144.600 he isn't on the cluster
-
-
-
- The <freq> is compared against the available bands set up in the
- cluster. See SHOW/BANDS for more information.
-
- 11.37. export (9)
-
- export <msgno> <filename> Export a message to a file
-
-
- 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
-
-
- 11.38. export_users (9)
-
- export_users [<filename>] Export the users database to ascii
-
-
- 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.
-
-
- 11.39. filtering (0)
-
- filtering Filtering things in DXSpider
-
-
- 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
-
- 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
- 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.
-
-
- 11.40. forward/latlong (8)
-
- forward/latlong <node_call> Send latitude and longitude information to
- another cluster
-
-
- 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 set/dxgrid enabled. This could be a LOT of information though,
- so it is not recommended on slow links.
-
-
- 11.41. forward/opername (1)
-
- forward/opername <call> Send out information on this <call> to all
- clusters
-
-
- 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.
-
-
- 11.42. help (0)
-
- help <cmd> Get help on a command
-
-
-
- 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.
-
-
- 11.43. init (5)
-
- init <node call> Re-initialise a link to an AK1A compatible node
-
-
- 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.
-
-
- 11.44. kill (0)
-
- kill <msgno> [<msgno> ..] Delete a message from the local system
-
-
- 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).
-
-
- 11.45. kill (5)
-
- kill <msgno> [<msgno> ...] Remove or erase a message from the system
- kill from <call> Remove all messages from a callsign
- kill to <call> Remove all messages to a callsign
-
-
- 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.
-
-
- 11.46. kill full (5)
-
- kill full <msgno> [<msgno>] Delete a message from the whole cluster
-
-
- 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!
-
-
- 11.47. kill/expunge (6)
-
- kill/expunge <msgno> [<msgno>..]Expunge a message
-
-
- 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.
-
-
-
- 11.48. links (0)
-
- links Show which nodes are physically connected
-
-
- This is a quick listing that shows which links are connected and some
- information about them. See WHO for a list of all connections.
-
-
-
- 11.49. load/aliases (9)
-
- load/aliases Reload the command alias table
-
-
- 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.
-
-
- 11.50. load/badmsg (9)
-
- load/badmsg Reload the bad message table
-
-
- 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.
-
-
- 11.51. load/badwords (9)
-
- load/badwords Reload the bad words table
-
-
- 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.
-
-
- 11.52. load/bands (9)
-
- load/bands Reload the band limits table
-
-
- Reload the /spider/data/bands.pl file if you have changed it manually
- whilst the cluster is running.
-
-
- 11.53. load/cmd_cache (9)
-
- load/cmd_cache Reload the automatic command cache
-
- 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.
-
-
- 11.54. load/forward (9)
-
- load/forward Reload the msg forwarding routing table
-
- Reload the /spider/msg/forward.pl file if you have changed it manually
- whilst the cluster is running.
-
-
- 11.55. load/messages (9)
-
- load/messages Reload the system messages file
-
-
- 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'
-
-
- 11.56. load/prefixes (9)
-
- load/prefixes Reload the prefix table
-
-
- Reload the /spider/data/prefix_data.pl file if you have changed it
- manually whilst the cluster is running.
-
-
- 11.57. merge (5)
-
- merge <node> [<no spots>/<no wwv>] Ask for the latest spots and WWV
-
-
- 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).
-
-
- 11.58. msg (9)
-
- msg <cmd> <msgno> [data ...] Alter various message parameters
-
-
- 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.
-
-
-
- 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
-
-
-
- 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.
-
-
- 11.59. pc (8)
-
- pc <call> <text> Send text (eg PC Protocol) to <call>
-
-
- 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!!!
-
-
- 11.60. ping (1)
-
- ping <node> Check the link quality between nodes
-
-
- 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.
-
-
-
- 11.61. rcmd (1)
-
- rcmd <node call> <cmd> Send a command to another DX cluster
-
-
- 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.
-
-
- 11.62. read (0)
-
- read Read the next unread personal message addressed to you
- read <msgno> Read the specified message
-
-
- You can read any messages that are sent as 'non-personal' and also any
- message either sent by or sent to your callsign.
-
-
-
- 11.63. read (extended for sysops) (5)
-
- read <msgno> Read a message on the system
-
-
- As a sysop you may read any message on the system
-
-
- 11.64. reject/announce
-
- reject/announce [0-9] <pattern> Set a reject filter for announce
-
-
- 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:-
-
-
-
- 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)
-
-
-
- some examples:-
-
-
-
- rej/ann by_zone 14,15,16 and not by G,M,2
-
-
-
- You can use the tag 'all' to reject everything eg:
-
-
-
- rej/ann all
-
-
-
- but this probably for advanced users...
-
-
- 11.65. reject/announce (extended for sysops) (8)
-
- reject/announce <call> [input] [0-9] <pattern> Announce filter sysop
- version
-
-
- This version allows a sysop to set a filter for a callsign as well as
- the default for nodes and users eg:-
-
-
-
- reject/ann by G,M,2
- reject/ann input node_default by G,M,2
- reject/ann user_default by G,M,2
-
-
-
- 11.66. reject/route (8)
-
- reject/route <call> [0-9] <pattern> Set an 'reject' filter line for
- routing
-
-
- Create an 'reject this routing PC Protocol' line for a filter.
-
-
- 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:-
-
-
-
- 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>
-
-
-
- some examples:-
-
-
-
- rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes)
-
-
-
- You can use the tag 'all' to reject everything eg:
-
-
-
- rej/route all (equiv to [very] restricted mode)
-
-
-
- 11.67. reject/spots (0)
-
- reject/spots [0-9] <pattern> Set a reject filter line for spots
-
-
- 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:-
-
-
-
- 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>
-
-
-
- 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:-
-
-
-
- rej/spot 1 on hf
- rej/spot 2 on vhf and not (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
- You can use the tag 'all' to reject everything eg:
-
-
-
- rej/spot 3 all
-
-
-
- but this probably for advanced users...
-
-
- 11.68. reject/spots (extended for sysops) (8)
-
- reject/spots <call> [input] [0-9] <pattern> Reject spot filter sysop
- version
-
-
- This version allows a sysop to set a filter for a callsign as well as
- the default for nodes and users eg:-
-
-
-
- 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
-
-
-
- 11.69. reject/wcy (0)
-
- reject/wcy [0-9] <pattern> Set a reject WCY filter
-
-
- It is unlikely that you will want to do this, but if you do then you
- can filter on the following fields:-
-
-
-
- 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>
-
-
-
- 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.
-
-
-
- 11.70. reject/wcy (extended for sysops) (8)
-
- reject/wcy <call> [input] [0-9] <pattern> WCY reject filter sysop
- version
-
-
- 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
-
-
- 11.71. reject/wwv (0)
-
- reject/wwv [0-9] <pattern> Set a reject WWV filter
-
-
- It is unlikely that you will want to do this, but if you do then you
- can filter on the following fields:-
-
-
-
- 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>
-
-
-
- for example
-
-
-
- reject/wwv by_zone 14,15,16
-
-
-
- is probably the only useful thing to do (which will only show WWV
- broadcasts by stations in the US).
-
- See HELP FILTER for information.
-
-
- 11.72. reject/wwv (extended for sysops) (8)
-
- reject/wwv <call> [input] [0-9] <pattern> WWV reject filter sysop
- version
-
-
- This version allows a sysop to set a filter for a callsign as well as
- the default for nodes and users eg:-
-
-
-
- reject/wwv db0sue-7 1 by_zone 4
- reject/wwv node_default all
-
- reject/wwv user_default by W
-
- 11.73. reply (0)
-
- reply Reply (privately) to the last message that you have read
- reply <msgno> Reply (privately) to the specified message
- reply B <msgno> Reply as a Bulletin to the specified message
- reply NOPrivate <msgno> Reply as a Bulletin to the specified message
- reply RR <msgno> Reply to the specified message with read receipt
-
-
- 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)
-
-
- 11.74. send (0)
-
- send <call> [<call> ...] Send a message to one or more callsigns
- send RR <call> Send a message and ask for a read receipt
- send COPY <msgno> <call> Send a copy of a message to someone
- send PRIVATE <call> Send a personal message
- send NOPRIVATE <call> Send a message to all stations
-
-
- 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:-
-
-
-
- SEND RR COPY 123 PRIVATE G1TLH G0RDI
-
-
-
- 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
-
-
- 11.75. set/address (0)
-
- set/address <your_address> Record your postal address
-
-
- Literally, record your address details on the cluster.
-
-
- 11.76. set/announce (0)
-
- set/announce Allow announce messages
-
-
- Allow announce messages to arrive at your terminal.
-
- 11.77. set/arcluster (5)
-
- set/arcluster <node_call> [<node_call> ...] Make the node_call an AR-
- Cluster type node
-
-
- Set the node_call as an AR-Cluster type node
-
-
- 11.78. set/baddx (8)
-
- set/baddx <call> Stop words we do not wish to see in the callsign
- field of a dx spot being propagated
-
-
- 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:-
-
-
-
- set/baddx FORSALE VIDEO FR0G
-
-
-
- To allow a word again, use the following command ...
-
-
-
- unset/baddx VIDEO
-
-
-
- 11.79. set/badnode (6)
-
- set/badnode <node_call> Stop spots from this node_call being
- propagated
-
-
- 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:-
-
-
-
- set/badnode K1TTT
-
-
-
- will stop anything from K1TTT (including any SSID's)
-
-
-
- unset/badnode K1TTT
-
-
-
- will allow spots from him again.
-
- Use with extreme care. This command may well be superceded by
- FILTERing.
-
-
- 11.80. set/badspotter (8)
-
- set/badspotter <call> Stop spots from this callsign being propagated
-
-
- 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:-
-
-
-
- set/badspotter VE2STN
-
-
-
- will stop anything from VE2STN. If you want SSIDs as well then you
- must enter them specifically.
-
-
-
- unset/badspotter VE2STN
-
-
-
- will allow spots from him again.
-
- Use with extreme care. This command may well be superceded by
- FILTERing.
-
-
- 11.81. set/badword (8)
-
- set/badword <word> Stop things with this word being propogated
-
-
- 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.
-
-
-
- 11.82. set/beep (0)
-
- set/beep Add beeps to terminal messages
-
- Add a beep to DX and other terminal messages.
-
-
- 11.83. set/bbs (5)
-
- set/bbs <call> [<call>..]Make <call> a BBS
-
-
- 11.84. set/clx (5)
-
- set/clx <node_call> [<node_call> ...] Make the node_call a CLX type
- node
-
-
- Set the node_call as a CLX type node
-
-
- 11.85. set/debug (9)
-
- set/debug <name> Add a debug level to the debug set
-
-
- 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 show/debug command.
-
- You can remove a debug level with unset/debug <name>
-
-
- 11.86. set/dx (0)
-
- set/dxAllow DX messages to arrive at your terminal
-
-
- You can stop DX messages with the unset/dx command
-
-
- 11.87. set/dxgrid (0)
-
- set/dxgridAllow grid squares on the end of DX messages
-
-
- Some logging programs do not like the additional information at the
- end of a DX spot. If this is the case, use the unset/dxgrid command
- to remove the grid squares.
-
-
- 11.88. set/dxnet (5)
-
- set/dxnet <node_call> [<node_call> ...] Make the node_call a DXNet
- type node
-
-
- Set the node_call as a DXNet type node
-
-
- 11.89. set/echo (0)
-
- set/echo Make the cluster echo your input
-
-
- 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 unset/echo command
-
- The setting is stored in your user profile.
-
- YOU DO NOT NEED TO USE THIS COMMAND IF YOU ARE CONNECTED VIA AX25.
-
-
- 11.90. set/email (0)
-
- set/email <email_address> Set email address(es) and forward your
- personals
-
-
- 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
-
-
- 11.91. set/here (0)
-
- set/here Set the here flag
-
-
- 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
- unset/here command to let people know you are away. This simply puts
- brackets around your callsign to indicate you are not available.
-
-
- 11.92. set/homenode (0)
-
- set/homenode <node_call> Set your home cluster
-
-
- 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:-
-
-
-
- SET/HOMENODE gb7djk
-
-
-
- 11.93. set/hops (8)
-
- set/hops <node_call> ann|spots|wwv|wcy <n> Set hop count
-
-
- 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.
- eg:
- set/hops gb7djk ann 10
- set/hops gb7mbc spots 20
-
-
-
- Set SHOW/HOPS for information on what is already set. This command
- creates a filter and works in conjunction with the filter system.
-
-
- 11.94. set/isolate (9)
-
- set/isolate <node call> Isolate a node from the rest of the network
-
-
- 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.
-
-
- 11.95. set/language (0)
-
- set/language <language> Set the language you wish to use
-
-
- You can select the language that you want the cluster to use.
- Currently the languages available are en (English) and nl (Dutch).
-
-
- 11.96. set/location (0)
-
- set/location <lat and long> Set your latitude and longitude
-
-
- You can set your latitude and longitude manually or alternatively use
- the set/qra command which will do the conversion for you.
-
-
-
- set/location 54 04 N 2 02 E
-
-
-
- 11.97. set/sys_location (9)
-
- set/sys_location <lat & long> Set your cluster latitude and longitude
-
-
- 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:-
-
-
- SET/LOCATION 52 22 N 0 57 E
-
-
-
- 11.98. set/logininfo (0)
-
- set/logininfo Show logins and logouts of nodes and users
-
-
- Show users and nodes when they log in and out of the local cluster.
- You can stop these messages by using the unset/logininfo command.
-
-
-
- 11.99. set/lockout (9)
-
- set/lockout <call> Stop a callsign connecting to the cluster
-
-
- You can show who is locked out with the show/lockout command. To
- allow the user to connect again, use the unset/lockout command.
-
-
- 11.100. set/name (0)
-
- set/name <your_name> Set your name
-
-
- Tell the cluster what your name is, eg:-
-
-
-
- set/name Dirk
-
-
-
- 11.101. set/node (9)
-
- set/node <call> [<call> ...] Make the callsign an AK1A cluster
-
-
- 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
-
-
-
- set/spider
- set/dxnet
- set/clx
- set/arcluster
-
-
-
- To see what your nodes are set to, use the show/nodes command.
-
-
-
- 11.102. set/obscount (9)
-
- set/obscount <count> <node call> Set the 'pump-up' obsolescence
- counter
-
-
- 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.
-
-
- 11.103. set/page (0)
-
- set/page <n> Set the number of lines per page
-
-
- 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.
-
-
-
- SET/PAGE 30
- SET/PAGE 0
-
-
-
- The setting is stored in your user profile.
-
-
- 11.104. set/password (0)
-
- set/password Set your own password
-
-
- 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.
-
-
- 11.105. set/password (9)
-
- set/password <callsign> <string> Set a users password
-
-
- 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.
-
-
- 11.106. set/pinginterval (9)
-
- set/pinginterval <time> <node call> Set the ping time to neighbouring
- nodes
-
-
- 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.
-
-
- 11.107. set/privilege (9)
-
- set/privilege <n> <call> [<call> ...] Set the privilege level on a
- call
-
-
- Set the privilege level on a callsign. The privilege levels that
- pertain to commands are as default:-
-
-
-
- 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.
-
-
-
- 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.
-
-
-
- 11.108. set/spider (5)
-
- set/spider <node_call> [<node_call> ...] Make the node_call a DXSpider
- type node
-
-
- Set the node_call as a DXSpider type node
-
-
- 11.109. set/sys_qra (9)
-
- set/sys_qra <locator> Set your cluster QRA locator
-
-
- 11.110. set/qra (0)
-
- set/qra <locator> Set your QRA locator
-
-
- 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:-
-
-
-
- SET/QRA JO02LQ
-
-
-
- 11.111. set/qth (0)
-
- set/qth <your QTH> Set your QTH
-
-
- Tell the system where your are. For example:-
-
-
-
- set/qth East Dereham, Norfolk
-
-
-
- 11.112. set/register (9)
-
- set/register <call> Mark a user as registered
-
-
- 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
-
-
- 11.113. set/talk (0)
-
- set/talk Allow talk messages to be seen at your console
-
-
- Allow talk messages to arrive at your console. You can switch off
- talks with the unset/talk command.
-
-
- 11.114. set/wcy (0)
-
- set/wcy Allow WCY messages to be seen at your console
-
-
- Allow WCY information to be seen at your console. You can switch off
- WCY messages with the unset/wcy command.
-
-
- 11.115. set/wwv (0)
-
- set/wwv Allow WWV messages to be seen at your console
-
-
- Allow WWV information to be seen at your console. You can switch off
- WWV messages with the unset/wwv command.
-
-
- 11.116. set/wx (0)
-
- set/wx Allow WX messages to be seen at your console
-
-
- Allow WX information to be seen at your console. You can switch off
- WX messages with the unset/wx command.
-
-
- 11.117. show/baddx (1)
-
- show/baddxShow all the bad dx calls in the system
-
-
- Display all the bad dx callsigns in the system, see SET/BADDX for more
- information.
-
-
- 11.118. show/badnode (6)
-
- show/badnode Show all the bad nodes in the system
-
-
- Display all the bad node callsigns in the system, see SET/BADNODE for
- more information.
-
-
- 11.119. show/badspotter (1)
-
- show/badspotter Show all the bad spotters in the system
-
-
- Display all the bad spotter's callsigns in the system, see
- SET/BADSPOTTER for more information.
-
-
- 11.120. show/badword (1)
-
- show/badword Show all the bad words in the system
-
-
- Display all the bad words in the system, see SET/BADWORD for more
- information.
-
-
- 11.121. show/configuration (0)
-
- show/configuration [<node>] Show all visible nodes and their users
-
-
- This command allows you to see all the users that can be seen and the
- nodes to which they are connected. With the optional node, 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
-
-
- 11.122. show/configuration/node (0)
-
- show/configuration/node Show all the nodes connected
-
-
- Show all the nodes connected locally and the nodes they have
- connected.
-
-
- 11.123. show/connect (1)
-
- show/connect Show all the active connections
-
-
- This command shows information on all the active connections known to
- the node. This command gives slightly more information than WHO.
-
-
- 11.124. show/date (0)
-
- show/date [<prefix>|<callsign>] Show the local time
-
-
- 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.
-
-
- 11.125. show/debug (9)
-
- show/debug Show what levels of debug you are logging
-
-
- The levels can be set with set/debug
-
-
-
- 11.126. show/dx (0)
-
- show/dx [options] interrogate the spot database
-
-
- 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:-
-
-
-
- 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.
-
-
-
- e.g.
-
-
-
- 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
-
-
-
- 11.127. show/dxcc (0)
-
- show/dxcc <prefix> Interrogate the spot database by country
-
-
- 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.
-
-
-
- SH/DXCC G
- SH/DXCC W on 20m info iota
-
-
-
- 11.128. sh/dxstats (0)
-
- sh/dxstats Show the DX Statistics for last 31 days
-
-
- Show the total DX spots for the last 31 days
-
-
-
- 11.129. show/files (0)
-
- show/files [<filearea> [<string>]] List the contents of a filearea
-
-
- 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:-
-
-
-
- SH/FILES <filearea>
-
-
-
- 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:-
-
-
-
- SH/FILES bulletins arld*
-
-
-
- See also TYPE - to see the contents of a file.
-
-
- 11.130. show/filter (0)
-
- show/filter Show the filters you have set
-
- Show the contents of all the filters that are set by you. This command
- displays all the filters set - for all the various categories.
-
-
- 11.131. show/filter (extended for sysops) (5)
-
- show/filter <callsign> Show the filters set by <callsign>
-
-
- A sysop can look at any filters that have been set.
-
-
- 11.132. show/hfstats (0)
-
- show/hfstats Show the HF DX Statistics for last 31 days
-
-
- Show the HF DX spots breakdown by band for the last 31 days
-
-
- 11.133. show/hftable (0)
-
- show/hftable Show the HF DX Spotter Table for your country
-
-
- Show the HF DX Spotter table for your country for the last 31 days
-
-
- 11.134. show/hops (8)
-
- show/hops <node_call> [ann|spots|wcy|wwv|] Show the hop counts for a
- node
-
-
- 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.
-
-
- 11.135. show/isolate (1)
-
- show/isolate Show a list of isolated nodes
-
-
- Show which nodes are currently set to be isolated.
-
-
- 11.136. show/lockout (9)
-
- show/lockout Show a list of excluded callsigns
-
-
- Show a list of callsigns that have been excluded (locked out) of the
- cluster locally with the set/lockout command
-
-
- 11.137. show/log (8)
-
- show/log [<callsign>] Show excerpts from the system log
-
-
- 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.
-
-
- 11.138. show/moon (0)
-
- show/moon [<prefix>|<callsign>] Show moon rise and set times
-
-
- 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:-
-
-
-
- SH/MOON
- SH/MOON G1TLH W5UN
-
-
-
- 11.139. show/muf (0)
-
- show/muf <prefix> [<hours>][long] Show the likely propagation to
- <prefix>
-
-
- 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:-
-
-
-
- SH/MUF W
-
-
-
- produces:
-
-
-
- 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
-
-
-
- indicating that you will have weak, fading circuits on top band and
- 80m but usable signals on 40m (about S3).
-
- inputting:-
-
-
-
- SH/MUF W 24
-
-
-
- will get you the above display, but with the next 24 hours worth of
- propagation data.
-
-
-
- SH/MUF W L 24
- SH/MUF W 24 Long
-
-
-
- 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.
-
-
- 11.140. show/newconfiguration (0)
-
- show/newconfiguration [<node>] Show all the nodes and users visible
-
-
- 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
-
-
- 11.141. show/newconfiguration/node (0)
-
- show/newconfiguration/node Show all the nodes connected locally
-
-
- Show all the nodes connected to this node in the new format.
-
-
- 11.142. show/node (1)
-
- show/node [<node_call> ...] Show the type and version number of nodes
-
-
- 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.
-
-
- 11.143. show/prefix (0)
-
- show/prefix <callsign> Interrogate the prefix database
-
-
- 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
-
-
-
- 11.144. show/program (5)
-
- show/program Show the locations of all the included program modules
-
-
- 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.
-
-
- 11.145. show/qra (0)
-
- show/qra <locator> [<locator>] Show the distance between locators
- show/qra <lat> <long> Convert latitude and longitude to a locator
-
-
- 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:-
-
-
-
- SH/QRA IO92QL
- SH/QRA JN06 IN73
-
- 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:-
-
-
-
- SH/QRA 52 41 N 0 58 E
-
-
-
- 11.146. show/qrz (0)
-
- show/qrz <callsign> Show any callbook details on a callsign
-
-
- 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
-
-
- 11.147. show/registered (9)
-
- show/registered [<prefix>[ Show the registered users
-
-
- 11.148. show/route (0)
-
- show/route <callsign> Show the route to <callsign>
-
-
- This command allows you to see to which node the callsigns specified
- are connected. It is a sort of inverse sh/config.
-
-
-
- sh/route n2tly
-
-
-
- 11.149. show/satellite (0)
-
- show/satellite <name> [<hours> <interval>] Show satellite tracking
- data
-
-
- 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:-
-
-
-
- SH/SAT AO-10
- SH/SAT FENGYUN1 12 2
-
-
-
- 11.150. show/sun (0)
-
- show/sun [<prefix>|<callsign>] Show sun rise and set times
-
-
- 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:-
-
-
-
- SH/SUN
- SH/SUN G1TLH K9CW ZS
-
-
-
- 11.151. show/time (0)
-
- show/time [<prefix>|<callsign>] Show the local time
-
-
- 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.
-
-
- 11.152. show/vhfstats (0)
-
- show/vhfstats Show the VHF DX Statistics for last 31 days
-
-
- Show the VHF DX spots breakdown by band for the last 31 days
-
-
- 11.153. show/vhftable (0)
-
- show/vhftable Show the VHF DX Spotter Table for your country
-
- Show the VHF DX Spotter table for your country for the last 31 days
-
-
- 11.154. show/wcy (0)
-
- show/wcy Show the last 10 WCY broadcasts
- show/wcy <n> Show the last <n> WCY broadcasts
-
-
- Display the most recent WCY information that has been received by the
- system
-
-
- 11.155. show/wwv (0)
-
- show/wwv Show the last 10 WWV broadcasts
- show/wwv <n> Show the last <n> WWV broadcasts
-
-
- Display the most recent WWV information that has been received by the
- system
-
-
-
- 11.156. shutdown (5)
-
- shutdown Shutdown the cluster
-
-
- Shutdown the cluster and disconnect all the users. If you have Spider
- set to respawn in /etc/inittab it will of course restart.
-
-
- 11.157. spoof (9)
-
- spoof <callsign> <command> Run commands as another user
-
-
- 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.
-
-
- 11.158. stat/db (5)
-
- stat/db <dbname> Show the status of a database
-
-
- 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.
-
-
- 11.159. stat/channel (5)
-
- stat/channel <callsign> Show the status of a channel on the cluster
-
-
- 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.
-
- 11.160. stat/msg (5)
-
- stat/msg <msgno> Show the status of a message
-
-
- 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.
-
-
- If no message number is given then the status of the message system is
- displayed.
-
-
- 11.161. stat/route_node (5)
-
- stat/route_node <callsign> Show the data in a Route::Node object
-
-
- 11.162. stat/route_user (5)
-
- stat/route_user <callsign> Show the data in a Route::User object
-
-
- 11.163. stat/user (5)
-
- stat/user <callsign> Show the full status of a user
-
-
- 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.
-
-
- 11.164. sysop (0)
-
- sysop Regain your privileges if you login remotely
-
-
- 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 :-):
-
-
-
- password = 012345678901234567890123456789
- > sysop
- 22 10 15 17 3
-
-
-
- you type:-
-
-
-
- aa2bbbb0ccc5ddd7xxx3n
- or 2 0 5 7 3
- or 20573
-
-
-
- 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.
-
-
- 11.165. talk (0)
-
- talk <callsign> Enter talk mode with <callsign>
- talk <callsign> <text> Send a text message to <callsign>
- talk <callsign> > <node_call> [<text>] Send a text message to
- <callsign> via <node_call>
-
-
- 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:-
-
-
-
- /DX 14001 G1TLH What's a B class licensee doing on 20m CW?
- /HELP talk
-
-
-
- To leave talk mode type:
-
-
-
- /EX
-
-
-
- 11.166. type (0)
-
- type <filearea>/<name> Look at a file in one of the fileareas
-
-
- 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:-
-
-
-
- TYPE bulletins/arld051
-
-
-
- See also SHOW/FILES to see what fileareas are available and a list of
- content.
-
-
- 11.167. who (0)
-
- who Show who is physically connected locally
-
-
- This is a quick listing that shows which callsigns are connected and
- what sort of connection they have
-
-
- 11.168. wx (0)
-
- wx <text> Send a weather message to local users
- wx full <text> Send a weather message to all cluster users
-
-
- Weather messages can sometimes be useful if you are experiencing an
- extreme that may indicate enhanced conditions
-
-
- 11.169. wx (enhanced for sysops) (5)
-
- wx sysop <text> Send a weather message to other clusters only
-
-
- Send a weather message only to other cluster nodes and not to general
- users.
-
-
-
projects / spider.git / blobdiff