X-Git-Url: http://gb7djk.dxcluster.net/gitweb/gitweb.cgi?a=blobdiff_plain;f=sgml%2Fadminmanual.sgml;fp=sgml%2Fadminmanual.sgml;h=0000000000000000000000000000000000000000;hb=3d66b51182cb1939154d96def02efb45784958c0;hp=01a8c57188a7f0e5ff7e96b69ae592132d7f3944;hpb=bccf827cfc80f9871efc8a25f9bb69f99c771d77;p=spider.git diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml deleted file mode 100644 index 01a8c571..00000000 --- a/sgml/adminmanual.sgml +++ /dev/null @@ -1,1816 +0,0 @@ - - -
- - - -The DXSpider Administration Manual v1.50 -Ian Maude, G0VGS, (g0vgs@gb7mbc.net), and -Charlie Carroll, K1XX, (k1xx@ptcnh.net) -March 2003 revision 0.5 - - -A reference for SysOps of the DXSpider DXCluster program. - - - - - - - -Routing and Filtering - -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). - -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. - -The node_default filter - -

-All normal systems should have a default routing filter and it should -usually be set to send only the normal, unlooped, view of your -"national" network. Here in the UK that means nodes from the UK and -Eire, in EU it is more complex as the networks there grew up in a more -intertwined way. - -

-The generic commands are:- - - -reject/route node_default <filter_option> - -or - -accept/route node_default <filter_option> - - -where filter_option is one of the following ... - - -call <prefixes> -call_dxcc <numbers> -call_itu <numbers> -call_zone <numbers> -channel <prefixes> -channel_dxcc <numbers> -channel_itu <numbers> -channel_zone <numbers> - - -Please be careful if you alter this setting, it will affect -ALL your links! Remember, this is a default -filter for node connections, not a per link default. - -

-For the default routing filter then you have two real choices: either -a "national" view or the "safe" option of only your own -callsign. Examples of each (for my node: GB7DJK) are:- - - -acc/route node_default call_dxcc 61,38 -acc/route node_default call gb7djk - - -GB7DJK uses the first of these. The DXCC countries can be obtained from the -show/prefix command. - -

-The example filters shown control output TO all your -partner nodes unless they have a specific filter applied to them (see -next section). - -

-It is also possible to control the incoming routing -information that you are prepared to accept FROM your partner -nodes. The reason this is necessary is to make sure that stuff like -mail, pings and similar commands a) go down the correct links and b) -don't loop around excessively. Again using GB7DJK as an example a typical -default input filter would be something like: - - -rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38 - - -What this does is accept node and user information for our national -network from nodes that are in our national network, but rejects such -information from anyone else. Although it doesn't explicitly say so, -by implication, any other node information (not from the UK and Eire) -is accepted. - -

-As I imagine it will take a little while to get one's head around all of -this you can study the effect of any rules that you try by watching the -debug output after having done:- - - -set/debug filter - - -After you have got tired of that, to put it back the way it was:- - - -unset/debug filter - - -General route filtering - -

-Exactly the same rules apply for general route filtering. You would -use either an accept filter or a reject filter like this ... - - -reject/route <node_call> <filter_option> - -or - -accept/route <node_call> <filter_option> - - -

-Here are some examples of route filters ... - - -rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes) -rej/route all (equiv to [very] restricted mode) -acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes) -acc/route gb7djk call gb7djk (equiv to SET/ISOLATE) - - -In practice you will either be opening the default filter out for a -partner by defining a specific filter for that callsign:- - - -acc/route gb7baa all -acc/route gb7baa input all - - -or restricting it quite a lot, in fact making it very nearly like an -isolated node, like this:- - - -acc/route pi4ehv-8 call gb7djk -rej/route pi4ehv-8 input call_dxcc 61,38 - - -This last example takes everything except UK and Eire from PI4EHV-8 -but only sends him my local configuration (just a PC19 for GB7DJK and -PC16s for my local users). - -

-It is possible to write much more complex rules, there are up -to 10 accept/reject pairs per callsign per filter. For more information -see the next section. - - -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. - -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 - - -Filter options - -

-You can filter in several different ways. The options are listed in the -various helpfiles for accept, reject and filter. - -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. - -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. - -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. - -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. - -Isolating networks - -

-It is possible to isolate networks from each other on a "gateway" node using the - set/isolate <node_call> command. - -

-The effect of this is to partition an isolated network completely from another -node connected to your node. Your node will appear on and otherwise behave -normally on every network to which you are connected, but data from an isolated -network will not cross onto any other network or vice versa. However all the -spot, announce and WWV traffic and personal messages will still be handled -locally (because you are a real node on all connected networks), that is locally -connected users will appear on all networks and will be able to access and -receive information from all networks transparently. All routed messages will -be sent as normal, so if a user on one network knows that you are a gateway for -another network, he can still still send a talk/announce etc message via your -node and it will be routed across. - -

-If you use isolate on a node connection you will continue to receive -all information from the isolated partner, however you will not pass -any information back to the isolated node. There are times when you -would like to forward only spots across a link (maybe during a contest -for example). To do this, isolate the node in the normal way and use -an acc/spot >call< all filter to override the isolate. - -Other filters - -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 = ( -'B', 'T', 'SALE', -'B', 'T', 'WANTED', -'B', 'S', 'WANTED', -'B', 'S', 'SALE', -'B', 'S', 'WTB', -'B', 'S', 'WTS', -'B', 'T', 'FS', -); - - -

-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. - - -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. - -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. - -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. - -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. - -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. - -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 = ( -'B', 'T', 'LOCAL', 'F', [ qw(GB7MBC) ], -'B', 'T', 'ALL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'UK', 'F', [ qw(GB7BAA GB7ADX) ], -'B', 'T', 'QSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'QSLINF', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'DX', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'DXINFO', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'DXNEWS', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'DXQSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'SYSOP', 'F', [ qw(GB7BAA GB7ADX) ], -'B', 'T', '50MHZ', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -); - - -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. - -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. - -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 > - - -Filtering mail - -

-This is described in the section on Other filters so I will not -duplicate it here. - -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. - -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. - -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 - -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. - -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. - -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. - -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 > - - -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 ... - - -'^sh\w*/buc', 'dbshow buckmaster', 'dbshow', - - -Now you can simply use show/buckmaster or an abreviation. - -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. - -Information, files and useful programs - -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. - -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. - -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. - -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! - -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 -'$' says match the end exactly. This prevents unwanted and unintentional matches -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. - - -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. - -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. - -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 - for allowing this access. - -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. - -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" ; - -'HOSTNAME' is the hostname of your cluster. - -'PORT' is the portnumber that you use to connect to your DxSpider via -telnet (see Listeners.pm) - -NOTE: If you can start the console but cannot connect to the cluster from it, -then it is possible that the machine you are on cannot resolve the hostname of -your cluster machine. If this is the case, you need to set your hostname -manually as above. - -You also need to set the $NODECALL variable. This prints the name of your -choosing (probably your cluster callsign) on the html page. - -You now can connect to Spider-Web via http://yourserver/cgi-bin/spider.cgi - - -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 . - -

-The following should help you get it all working. - -

-First you need to download the latest version of MRTG from . -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. - -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. - -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. - -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 - - -CVS - -CVS from a Linux platform - -

-CVS stands for "Concurrent Versions System" and the CVS for DXSpider is held -at . 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. - -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: - - - -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: - - - -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: - - - -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. - - - -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. - - - -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: - - - -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. - - - -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. - - - -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 - - -The DXSpider command set - -