X-Git-Url: http://scm.dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;ds=inline;f=sgml%2Fadminmanual.sgml;h=d6fb29940ca80701b12555b89ae1fed1aa24cd66;hb=c87553a14286b31db30d28decb1c0d5c8327e443;hp=cc6ba498f7cdbbc2030356d223cf5dcfbc2eb031;hpb=6624dcdf07d628e8d6a16fc6549edf40be25b7b2;p=spider.git diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml index cc6ba498..d6fb2994 100644 --- a/sgml/adminmanual.sgml +++ b/sgml/adminmanual.sgml @@ -36,31 +36,49 @@ handle loops well at all. It is therefore necessary to have some form of protection for these nodes.
-This is achieved by using filtering on a route basis. There is a
-default setting to help to protect the network, especially useful for new
-and inexperienced SysOps. The idea is simple. When Spider is started
-for the first time and a connection is made to or from another node,
-the default is to only send the nodes you already have that are in your
-own zone. For example, in the UK the default setting would be to send
-only UK nodes to any connection. This can be filtered further (down to
-a single node if needed) or expanded as required.
-
+In fact DXSpider has had a simple system for some time which is called
+
+The new functionality introduced in version 1.48 is 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 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
+(using the
-As mentioned in the introduction, a default setting exists. If this is
-all you want to use then that is fine, you have nothing else to do.
-However, if you want to make any alterations then you need to know
-a bit about filters.
-
-
-It is possible to reset the default setting for node connections should
-you wish to do so, however this can be dangerous to the network unless
-you have some experience in how all this works.... be careful! It is
-also possible to change settings for one connection only. You can,
-therefore, have many different filters set dependent on the amount of
-node links you have.
+
+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 do 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.
I should at this stage give a little bit of background on filters. All
@@ -69,22 +87,30 @@ 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.
+
+
-As discussed previously, a default setting exists that only sends nodes
-from your own zone. This can be overridden by using the default_node
-filter option like this ...
+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:-
where filter_option is one of the following ...
Please be careful if you alter this setting, it will affect
+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 example filters shown control
+It is also possible to control the
+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:-
+
+
@@ -116,20 +192,6 @@ or
accept/route <node_call> <filter_option>
-
-where filter_option is one of the following ...
-
-
Here are some examples of route filters ...
@@ -140,6 +202,31 @@ 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:-
+
+
+It is possible to do
@@ -156,7 +243,7 @@ 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
+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 ...
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.
+
@@ -442,24 +548,13 @@ 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 ....
-
-
-
-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 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.
+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:
+
-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 are 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.
+
@@ -2176,19 +2313,6 @@ Reload the /spider/cmd/Aliases file after you have editted it. You will need to
do this if you change this file whilst the cluster is running in order for the
changes to take effect.
-
-
-
-
-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.
-
@@ -2202,21 +2326,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.
-