X-Git-Url: http://scm.dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=txt%2Fadminmanual.txt;fp=txt%2Fadminmanual.txt;h=0000000000000000000000000000000000000000;hb=7d315a555a73d4a650405d0c2da48bacde2b1853;hp=622d272a33ae3adbfd16e83984aff182c687d745;hpb=1bb3ae1a09a6117d93c02041bff9b5cd2d4819ef;p=spider.git diff --git a/txt/adminmanual.txt b/txt/adminmanual.txt deleted file mode 100644 index 622d272a..00000000 --- a/txt/adminmanual.txt +++ /dev/null @@ -1,5302 +0,0 @@ - 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 - - or - - accept/route node_default - - - - where filter_option is one of the following ... - - - - call - call_dxcc - call_itu - call_zone - channel - channel_dxcc - channel_itu - channel_zone - - - - 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 - - or - - accept/route - - - - 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 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 - change TO callsign to - MSG FRom - change FROM callsign to - MSG PRrivate - set private flag - MSG NOPRrivate - unset private flag - MSG RR - set RR flag - MSG NORR - unset RR flag - MSG KEep - set the keep flag (message won't be deleted ever) - MSG NOKEep - unset the keep flag - MSG SUbject - change the subject to - MSG WAittime - remove any waiting time for this message - MSG NOREad - mark message as unread - MSG REad - 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 - - - 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 chain [...] - - - - This creates a chained database entry. The first database will be - scanned, then the second, the third etc... - - - - dbcreate remote - - - - 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] 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 eg: iota or qsl - by eg: G,M,2 - origin - origin_dxcc eg: 61,62 (from eg: sh/pre G) - origin_itu - origin_zone - by_dxcc - by_itu - by_zone - channel - wx 1 filter WX announces - dest 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 [input] [0-9] 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 [0-9] 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 the callsign of the thingy - call_dxcc eg: 61,62 (from eg: sh/pre G) - call_itu - call_zone - origin really the interface it came in on - origin_dxcc eg: 61,62 (from eg: sh/pre G) - origin_itu - origin_zone - - - - 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] 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 - 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 - 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 - call_zone - - Filters for the callsign of the station doing the spotting: - by - 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 - 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 - by_zone - - Filters for the callsign of the "node" doing the spotting: - origin - 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 - channel W1HR --> spots from the connected node W1HR will be spotted - channel K1QX --> spots from the connected user K1QX will be spotted - - info eg: iota or qsl - freq eg: 0/30000 or hf or hf/cw or 6m,4m,2m - on 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 [input] [0-9] 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] 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 eg: G,M,2 - origin - origin_dxcc eg: 61,62 (from eg: sh/pre G) - origin_itu - origin_zone - by_dxcc - by_itu - by_zone - channel - - - - 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 [input] [0-9] 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] 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 eg: G,M,2 - origin - origin_dxcc eg: 61,62 (from eg: sh/pre G) - origin_itu - origin_zone - by_dxcc - by_itu - by_zone - channel - - - - 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 [input] [0-9] 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 Send an announcement to local users - - - Send an announcement to LOCAL users only, where 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 Send an announcement cluster wide - - - This command will send your announcement across the whole cluster - network. - - - - 11.12. announce sysop (5) - - announce sysop - - - Send an announcement to Sysops only - - - 11.13. apropos (0) - - apropos Search the help database - - - Search the help database for (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 All|[ ...] 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 [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 [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 [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 [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 [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 Start a connection to another DX Cluster - - - Start a connection process that will culminate in a new connection to - the DX cluster . This process creates a new 'client' process - which will use the script in /spider/connect/ to effect the - 'chat' exchange necessary to traverse the network(s) to logon to the - cluster . - - - 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 Create a database entry - dbcreate chain [..] Create a chained database - entry - dbcreate remote 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/' 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 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 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 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 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 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 List all messages to - directory from List all messages from - directory subject List all messages with in subject - directory List last messages - directory - List messages message 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 - 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 [ ...] Disconnect a user or node - - - Disconnect any connected locally - - - 11.36. dx (0) - - dx [by ] Send a DX spot - - - This is how you send a DX Spot to other users. You can, in fact, now - enter the and the 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 is compared against the available bands set up in the - cluster. See SHOW/BANDS for more information. - - 11.37. export (9) - - export 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 [] 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 .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 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 Send out information on this 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 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 command which will search the help - database for the you specify and give you a list of likely - commands to look at with HELP. - - - 11.43. init (5) - - init 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 DISC/F ). - - Best of luck - you will need it. - - - 11.44. kill (0) - - kill [ ..] 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 [ ...] Remove or erase a message from the system - kill from Remove all messages from a callsign - kill to 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 [] 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 [..]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 [/] 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 [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 - change TO callsign to - MSG FRom - change FROM callsign to - MSG PRrivate - set private flag - MSG NOPRrivate - unset private flag - MSG RR - set RR flag - MSG NORR - unset RR flag - MSG KEep - set the keep flag (message won't be deleted ever) - MSG NOKEep - unset the keep flag - MSG SUbject - change the subject to - MSG WAittime - remove any waitting time for this message - MSG NOREad - mark message as unread - MSG REad - 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 - - This will display more information on the message than DIR does. - - - 11.59. pc (8) - - pc Send text (eg PC Protocol) to - - - 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 to " or - whatever. - - pc G1TLH Try doing that properly!!! - - - 11.60. ping (1) - - ping 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 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 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 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] 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 eg: iota or qsl - by eg: G,M,2 - origin - origin_dxcc eg: 61,62 (from eg: sh/pre G) - origin_itu - origin_zone - by_dxcc - by_itu - by_zone - channel - wx 1 filter WX announces - dest 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 [input] [0-9] 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 [0-9] 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 the callsign of the thingy - call_dxcc eg: 61,62 (from eg: sh/pre G) - call_itu - call_zone - origin really the interface it came in on - origin_dxcc eg: 61,62 (from eg: sh/pre G) - origin_itu - origin_zone - - - - 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] 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 eg: 0/30000 or hf or hf/cw or 6m,4m,2m - on same as 'freq' - call eg: G,PA,HB9 - info eg: iota or qsl - by - call_dxcc eg: 61,62 (from eg: sh/pre G) - call_itu - call_zone - by_dxcc - by_itu - by_zone - origin - channel - - - - 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 [input] [0-9] 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] 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 eg: G,M,2 - origin - origin_dxcc eg: 61,62 (from eg: sh/pre G) - origin_itu - origin_zone - by_dxcc - by_itu - by_zone - channel - - - - 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 [input] [0-9] 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] 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 eg: G,M,2 - origin - origin_dxcc eg: 61,62 (from eg: sh/pre G) - origin_itu - origin_zone - by_dxcc - by_itu - by_zone - channel - - - - 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 [input] [0-9] 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 Reply (privately) to the specified message - reply B Reply as a Bulletin to the specified message - reply NOPrivate Reply as a Bulletin to the specified message - reply RR 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 [ ...] Send a message to one or more callsigns - send RR Send a message and ask for a read receipt - send COPY Send a copy of a message to someone - send PRIVATE Send a personal message - send NOPRIVATE 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 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 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 [ ...] 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 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 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 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 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 [..]Make a BBS - - - 11.84. set/clx (5) - - set/clx [ ...] Make the node_call a CLX type - node - - - Set the node_call as a CLX type node - - - 11.85. set/debug (9) - - set/debug 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 - - - 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 [ ...] 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 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 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 ann|spots|wwv|wcy 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 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 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 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 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 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 Set your name - - - Tell the cluster what your name is, eg:- - - - - set/name Dirk - - - - 11.101. set/node (9) - - set/node [ ...] 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 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 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 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