X-Git-Url: http://scm.dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;ds=sidebyside;f=sgml%2Fadminmanual.sgml;h=f075b7988bb9a35e03316d921e811fe9350b3e60;hb=980b697bd47c8f575b1c9a7f01f9b01adc6746bd;hp=2f04bf2b1dfdbab3865fe882388277b708a4761a;hpb=b8ff94755eecda16276c449274c6a76c4f14a8d1;p=spider.git diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml index 2f04bf2b..f075b798 100644 --- a/sgml/adminmanual.sgml +++ b/sgml/adminmanual.sgml @@ -4,9 +4,9 @@ -
-Starting with version 1.13 there is simple hop control available on a per
-node basis. Also it is possible to isolate a network completely so that you
-get all the benefits of being on that network, but can't pass on information
-from it to any other networks you may be connected to (or vice versa).
-
-
-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 ...
+
+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
+
+The new functionality introduced in version 1.48 allows filtering the node
+and user protocol frames on a "per interface" basis. We call this
+
+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
+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
+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.
+
+
+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:-
-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.
-
-
-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.
-
-
-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
-nodes 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.
-
-
-The only limitation currently is that non-private messages cannot be passed down
-isolated links regardless of whether they are generated locally. This will change
-when the bulletin routing facility is added.
-
-
-If you use isolate on a node connection you will continue to receive all
-information from the isolated partner, however you will not pass any information
-back to the isolated node. There are times when you would like to forward only
-spots across a link (maybe during a contest for example). To do this, isolate
-the node in the normal way and put in a filter in the /spider/filter/spots
-directory to override the isolate. This filter can be very simple and consists
-of just one line ....
+where filter_option is one of the following ...
-There is a lot more on filtering in the next section.
-
-
-Filters can be set for spots, announcements and WWV. You will find the
-directories for these under /spider/filter. You will find some examples in
-the directories with the suffix .issue. There are two types of
-filter, one for incoming information and one for outgoing information.
-Outgoing filters are in the form CALLSIGN.pl and incoming filters
-are in the form in_CALLSIGN.pl. Filters can be set for both nodes
-and users.
-
-
-All filters work in basically the same way. There are several elements
-delimited by commas. There can be many lines in the filter and they are
-read from the top by the program. When writing a filter you need to think
-carefully about just what you want to achieve. You are either going to write
-a filter to accept or to reject. Think of a filter as
-having 2 main elements. For a reject filter, you would have a line or multiple
-lines rejecting the things you do not wish to receive and then a default line
-accepting everything else that is not included in the filter. Likewise, for an
-accept filter, you would have a line or multiple lines accepting the things you
-wish to receive and a default line rejecting everthing else.
+Please be careful if you alter this setting, it will affect
+
-In the example below, a user requires a filter that would only return SSB spots
-posted in Europe on the HF bands. This is achieved by first rejecting the CW
-section of each HF band and rejecting all of VHF, UHF etc based on frequency.
-Secondly, a filter rule is set based on CQ zones to only accept spots posted in
-Europe. Lastly, a default filter rule is set to reject anything outside the filter.
+
+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:-
-The actual elements of each filter are described more fully in the following
-sections.
+GB7DJK uses the first of these. The DXCC countries can be obtained from the
+
+The example filters shown control
-The elements of the Spot filter are ....
+
+It is also possible to control the
-There are 3 elements here to look at. Firstly, the action element. This is
-very simple and only 2 possible states exist, accept (1) or drop (0).
+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.
-
-The second element is the field_no. There are 13 possiblities to choose from
-here ....
+
+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:-
-The third element tells us what to expect in the fourth element. There are
-4 possibilities ....
+After you have got tired of that, to put it back the way it was:-
-The fifth element is simply the hops to set in this filter. This would only
-be used if the filter was for a node of course and overrides the hop count in
-hop_table.pl.
-
-
-So, let's look at an example spot filter. It does not matter in the example
-who the filter is to be used for. So, what do we need in the filter? We need
-to filter the spots the user/node requires and also set a default rule for
-anything else outside the filter. Below is a simple filter that stops spots
-arriving from outside Europe.
-
-
-So the filter is wrapped in between a pair of square brackets. This tells
-Spider to look in between these limits. Then each line is contained within
-its own square brackets and ends with a comma. Lets look carefully at the first
-line. The first element is 0 (drop). Therefore anything we put on this line
-will not be accepted. The next element is 4. This means we are filtering by
-the spotter. The third element is the letter "a" which tells the program to
-expect an alphanumeric expression in the fourth element. The fourth element
-is a list of letters separated by the pipe symbol.
+Exactly the same rules apply for general route filtering. You would
+use either an accept filter or a reject filter like this ...
-
-What this line does is tell the program to drop any spots posted by anyone in
-the USA, Canada or Japan.
-
-
-The second line is the default rule for anything else. The "d" tells us this
-and the line simply reads... accept anything else.
+
-You can add as many lines as you need to complete the filter but if there are
-several lines of the same type it is neater to enclose them all as one line.
-An example of this is where specific bands are set. We could write this like
-this ....
+or
-
-But the line below achieves the same thing and is more efficient ....
+Here are some examples of route filters ...
+In practice you will either be opening the default filter out for a
+partner by defining a specific filter for that callsign:-
+
-It should be noted that the filter will start to be used only once a user/node
-has logged out and back in again.
-
-I am not going to spend any more time on these filters now as they will become
-more "comprehensive" in the near future.
+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
-In general terms you can create a 'reject' or an 'accept' filter which can have
+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 ...
+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 ...
+
+
+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.
+
+
+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.
+
+ You can set a callsign specific hop count for any of the standard filter
+options so:-
+
+
+The set/hops command overrides any hops that you have set otherwise.
+
+
+You can set what hops have been set using the show/hops command.
+
+
+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.
-
-In the same way as mail, there are some types of spot we do not wish to pass on
-to users or linked cluster nodes. In the /spider/data directory you will find
-a file called baddx.pl.issue. Rename this to baddx.pl and edit the file. The
-original looks like this ....
+
+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.
-# the list of dx spot addresses that we don't store and don't pass on
+
+There are a number of commands that control whether a spot progresses
+any further by regarding it as "bad" in some way.
-package DXProt;
+
+A DX Spot has a number of fields which can be checked to see whether they
+contain "bad" values, they are: the DX callsign itself, the Spotter and
+the Originating Node.
-@baddx = qw
-
- FROG
- SALE
- FORSALE
- WANTED
- P1RATE
- PIRATE
- TEST
- DXTEST
- NIL
- NOCALL
-);
-
+There are a set of commands which allow the sysop to control whether a
+spot continues:-
-
-Again, this is simply a list of names we do not want to see in the spotted
-field of a DX callout.
+
-Create a file in /spider/data called badwords. The format is quite
-simple. Lines beginning with # are ignored so comments can be added. An
-example file is below ...
+a bad spotter:
-You can reload the file from the cluster prompt as sysop with load/badwords.
+
+From 1.48 onwards it will become increasingly possible to control DXSpider's
+operation with scripts of various kinds.
+
+
+In the first instance, in 1.48, the sysop can create, with their favorite
+text editor, files in the directory /spider/scripts which contain
+any legal command for a callsign or class of connection which will be executed
+at logon.
+
+
+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.
+
+
+In addition to the callsign specific scripts there are three others:-
+
+
+The user_default script is executed for every user that does
+
+The node_default script is executed for every node that doesn't
+have a specific script.
+
+
+There are a couple of examples in the /spider/scripts directory.
+
@@ -1326,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
@@ -1509,6 +1536,50 @@ default for nodes and users eg:-
accept/ann user_default by G,M,2
+
+
+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:-
+
+
+some examples:-
+
+
+You can use the tag 'all' to accept everything eg:
+
+
@@ -1695,7 +1766,9 @@ default for nodes and users eg:-
Send an announcement to LOCAL users only, where <text> is the text
-of the announcement you wish to broadcast
+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.
-
-
-Reload the /spider/data/baddx.pl file if you have changed it manually whilst
-the cluster is running. This table contains the DX Calls that, if spotted,
-will not be passed on. FR0G and TEST are classic examples.
-
@@ -2270,21 +2330,6 @@ 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.
-
-
-
-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.
-
@@ -2534,6 +2579,47 @@ default for nodes and users eg:-
reject/ann user_default by G,M,2
+
+
+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:-
+
+
+some examples:-
+
+
+You can use the tag 'all' to reject everything eg:
+
+
@@ -2884,6 +2970,13 @@ Use with extreme care. This command may well be superceded by FILTERing.
Add a beep to DX and other terminal messages.
+
+
+
@@ -3975,6 +4068,24 @@ Only the fields that are defined (in perl term) will be displayed.
This command shows the internal status of a message and includes information
such as to whom it has been forwarded, its size, origin etc etc.
+
+If no message number is given then the status of the message system is
+displayed.
+
+
+
+
+
+