From 7e7c5eedb4cccbb363db142d29438261b1c804da Mon Sep 17 00:00:00 2001 From: g0vgs Date: Thu, 20 Sep 2001 12:37:47 +0000 Subject: [PATCH] minor adds and changes --- html/adminmanual-1.html | 68 ++++++++++++++++++--------------- html/adminmanual-2.html | 2 +- html/adminmanual-4.html | 2 +- html/adminmanual-7.html | 10 ++--- html/adminmanual.html | 2 +- sgml/adminmanual.sgml | 84 +++++++++++++++++++++-------------------- sgml/spiderFAQ.sgml | 8 ++++ 7 files changed, 96 insertions(+), 80 deletions(-) diff --git a/html/adminmanual-1.html b/html/adminmanual-1.html index 1fb0df40..0a792494 100644 --- a/html/adminmanual-1.html +++ b/html/adminmanual-1.html @@ -32,21 +32,21 @@ 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 +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 is filtering the node +

The new functionality introduced in version 1.48 allows filtering the node and user protocol frames on a "per interface" basis. We call this route filtering. This is used instead of isolation.

What this really means is that you can control more or less completely -which PC protocol frames, to do with user and node management, pass to -each of your partner nodes. You can also limit what comes into your -node from your partners. You can even control the settings that your -partner node has for the routing information that it sends to you +which user and node management PC protocol frames pass to each of your +partner nodes. You can also limit what comes into your node from your +partners. It is even possible to control the settings that your partner +node has for the routing information that it sends to you (using the rcmd command).

1.2 Route Filters @@ -58,18 +58,25 @@ 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 do 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. -

-

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. +

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 @@ -117,7 +124,8 @@ channel_zone <numbers>

Please be careful if you alter this setting, it will affect -ALL your links! +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 @@ -154,9 +162,9 @@ 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:- +

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:- 

@@ -191,8 +199,8 @@ accept/route <node_call> <filter_option>
 

 

 
-rej/route gb7djk call_dxcc 61,38 (everything except  UK+EIRE nodes)
-rej/route all     (equiv to [very] restricted mode)
+rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes)
+rej/route all                    (equiv to [very] restricted mode)
 acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
 acc/route gb7djk call gb7djk     (equiv to SET/ISOLATE)
 

@@ -206,7 +214,8 @@ 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:- +

or restricting it quite a lot, in fact making it very nearly like an +isolated node, like this:- 

@@ -218,9 +227,9 @@ rej/route pi4ehv-8 input call_dxcc 61,38
 but only sends him my local configuration (just a PC19 for GB7DJK and
 PC16s for my local users).
 

-
It is possible to do much more complex rules, there are up to 10
-accept/reject pairs per callsign per filter. For more information see the 
-next section. 
+
It is possible to write 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
@@ -552,8 +561,7 @@ 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< allilter in the
-to override the isolate. 
+an acc/spot >call< all filter to override the isolate. 
 

 

 Next
diff --git a/html/adminmanual-2.html b/html/adminmanual-2.html
index 25afaa26..f8c10711 100644
--- a/html/adminmanual-2.html
+++ b/html/adminmanual-2.html
@@ -87,7 +87,7 @@ file will then be removed.
 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 checked to see whether they
+
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.
 

diff --git a/html/adminmanual-4.html b/html/adminmanual-4.html
index 37ff648b..a54fa8ce 100644
--- a/html/adminmanual-4.html
+++ b/html/adminmanual-4.html
@@ -24,7 +24,7 @@ any legal command for a callsign or class of connection which will be executed
 at logon.
 

 
 
-The filename are the callsign of the connection that you want the script to 
+The filename is the callsign of the connection that you want the script to 
 operate on, eg: /spider/scripts/g1tlh. The filenames are always in 
 lower case on those architectures where this makes a difference.
 

diff --git a/html/adminmanual-7.html b/html/adminmanual-7.html
index f75cfd19..50f14cdb 100644
--- a/html/adminmanual-7.html
+++ b/html/adminmanual-7.html
@@ -21,13 +21,9 @@ at
 that it is possible to update your DXSpider installation to the latest
 sources by using a few simple commands.
 

-
THIS IS NOT FOR THE FAINT HEARTED!!!  ONLY DO THIS IF YOU HAVE A TEST
-INSTALLATION OR ARE WILLING TO HAVE YOUR CLUSTER CRASH ON YOU!!!
-THIS MUST BE CONSIDERED AT LEAST BETA TESTING AND MAYBE EVEN ALPHA!!
-YOU HAVE BEEN WARNED!!!
-

-
DID I MENTION..... ONLY DO THIS IF YOU ARE WILLING TO ACCEPT THE
-CONSEQUENCES!!!
+
Please be aware that if you update your system using CVS, it is possible that
+you could be running code that is very beta and not fully tested.  There is
+a possibility that it could be unstable.
 

 
I am of course assuming that you have a machine with both DXSpider and
 Internet access running.
diff --git a/html/adminmanual.html b/html/adminmanual.html
index fc56acbf..0951c93c 100644
--- a/html/adminmanual.html
+++ b/html/adminmanual.html
@@ -15,7 +15,7 @@ Contents
 

 
The DXSpider Administration Manual v1.48

 
-
Ian Maude, G0VGS, (ianmaude@btinternet.com)
Version 1.48 August 2001 revision 1.1
+
Ian Maude, G0VGS, (ianmaude@btinternet.com)
Version 1.48 September 2001 revision 1.2
 

 A reference for SysOps of the DXSpider DXCluster program.
 

diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml
index d6fb2994..f075b798 100644
--- a/sgml/adminmanual.sgml
+++ b/sgml/adminmanual.sgml
@@ -6,7 +6,7 @@
 
 The DXSpider Administration Manual v1.48 
 Ian Maude, G0VGS, (ianmaude@btinternet.com)
-Version 1.48 August 2001 revision 1.1
+Version 1.48 September 2001 revision 1.2
 
 
 A reference for SysOps of the DXSpider DXCluster program.
@@ -37,23 +37,23 @@ 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 
+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 is filtering the node
+The new functionality introduced in version 1.48 allows filtering the node
 and user protocol frames on a "per interface" basis. We call this
 route filtering. This is used instead of
 isolation. 
 
 

 What this really means is that you can control more or less completely
-which PC protocol frames, to do with user and node management, pass to
-each of your partner nodes. You can also limit what comes into your
-node from your partners. You can even control the settings that your
-partner node has for the routing information that it sends to you
+which user and node management PC protocol frames pass to each of your 
+partner nodes. You can also limit what comes into your node from your 
+partners. It is even possible to control the settings that your partner 
+node has for the routing information that it sends to you 
 (using the rcmd command).
 
 Route Filters
@@ -66,19 +66,27 @@ 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 do 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.
+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.
 
 

-You will only require this functionality if you are
-"well-connected". What that means is that you are connected to several
-different parts of (say) the EU cluster and, at the same time, also
-connected to two or three places in the US which, in turn are
-connected back to the EU. This is called a "loop" and if you are
-seriously looped then you need filtering.
+To put it simply, you should not mix Isolation and Route Filtering.  It 
+will work, of sorts, but you will not get the expected results.  If you 
+are using Isolation sucessfully at the moment, do not get involved in 
+Route Filtering unless you have a good supply of aspirin!  Once you have 
+started down the road of Route Filtering, do not use Isolation either.
+Use one or the other, not both.
+
+

+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
@@ -125,7 +133,8 @@ channel_zone <numbers>
 
 
 Please be careful if you alter this setting, it will affect 
-ALL your links!
+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
@@ -164,9 +173,9 @@ 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:-
+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
@@ -196,8 +205,8 @@ accept/route <node_call> <filter_option>
 Here are some examples of route filters ...
 
 
-rej/route gb7djk call_dxcc 61,38 (everything except  UK+EIRE nodes)
-rej/route all     (equiv to [very] restricted mode)
+rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes)
+rej/route all                    (equiv to [very] restricted mode)
 acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
 acc/route gb7djk call gb7djk     (equiv to SET/ISOLATE)
 
@@ -210,7 +219,8 @@ 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:-
+or restricting it quite a lot, in fact making it very nearly like an 
+isolated node, like this:-
 
 
 acc/route pi4ehv-8 call gb7djk
@@ -222,9 +232,9 @@ but only sends him my local configuration (just a PC19 for GB7DJK and
 PC16s for my local users).
 
 

-It is possible to do much more complex rules, there are up to 10
-accept/reject pairs per callsign per filter. For more information see the 
-next section. 
+It is possible to write 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
@@ -553,8 +563,7 @@ 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< allacc/spot >call< all filter to override the isolate. 
 
 Other filters
 
@@ -630,7 +639,7 @@ 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 checked to see whether they
+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.
 
@@ -875,7 +884,7 @@ any legal command for a callsign or class of connection which will be executed
 at logon.
 
 
 
-The filename are the callsign of the connection that you want the script to 
+The filename is the callsign of the connection that you want the script to 
 operate on, eg: /spider/scripts/g1tlh. The filenames are always in 
 lower case on those architectures where this makes a difference.
 
@@ -1349,14 +1358,9 @@ that it is possible to update your DXSpider installation to the latest
 sources by using a few simple commands.
 
 

-THIS IS NOT FOR THE FAINT HEARTED!!!  ONLY DO THIS IF YOU HAVE A TEST
-INSTALLATION OR ARE WILLING TO HAVE YOUR CLUSTER CRASH ON YOU!!!
-THIS MUST BE CONSIDERED AT LEAST BETA TESTING AND MAYBE EVEN ALPHA!!
-YOU HAVE BEEN WARNED!!!
-
-

-DID I MENTION..... ONLY DO THIS IF YOU ARE WILLING TO ACCEPT THE
-CONSEQUENCES!!!
+Please be aware that if you update your system using CVS, it is possible that
+you could be running code that is very beta and not fully tested.  There is
+a possibility that it could be unstable.
 
 

 I am of course assuming that you have a machine with both DXSpider and
diff --git a/sgml/spiderFAQ.sgml b/sgml/spiderFAQ.sgml
index 2e53a412..a34a1efa 100644
--- a/sgml/spiderFAQ.sgml
+++ b/sgml/spiderFAQ.sgml
@@ -139,4 +139,12 @@ few steps to correct the problem.
 
 That should solve the problem.
 
+Since I last updated I seem to be getting duplicate spots appearing.
+
+

+What has probably happened is that the dupefile has got corrupted in
+some way.  Simply delete the /spider/data/dupefile and restart the
+cluster.  It may take a little time to become fully functional but
+should solve your problem.
+
 
-- 
2.34.1