X-Git-Url: http://dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=sgml%2Fadminmanual.sgml;h=967a4cb36fc83595a6efce35fd6d3fb283a4a793;hb=0c1c82537e95268c2ef2b23b4e9ef317a0119b2d;hp=d91dab680b17f3f7de83b9d1201f4e6f61e257b0;hpb=71ce25e28013877858408ae610c9eaf6d1fb001c;p=spider.git diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml index d91dab68..967a4cb3 100644 --- a/sgml/adminmanual.sgml +++ b/sgml/adminmanual.sgml @@ -6,7 +6,7 @@
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
+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 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
-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.
+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
-
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:-
-It is possible to do 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.
+
@@ -529,24 +558,12 @@ 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 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.
+
@@ -982,6 +1041,13 @@ 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.
+
+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.
+
@@ -1290,6 +1356,130 @@ 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
+The directory /spider/scripts 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. 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.
+
+
+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.
+
+
+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 ...
+
+
+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.
+
+
+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 ...
+
+
+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 ...
+
+
@@ -1299,14 +1489,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
@@ -2263,19 +2448,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.
-
@@ -2289,21 +2461,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.
-