X-Git-Url: http://dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=html%2Fadminmanual-2.html;h=af3f76b349d9431f230f005e10a70dfbcbe7d33b;hb=4137292dd2e67b2fe8fdfcfe431b25045719910c;hp=d606eb79060174a66f986027139004f1267c3a4c;hpb=4fa8a0251b64361c908d056393b46abece6d38be;p=spider.git diff --git a/html/adminmanual-2.html b/html/adminmanual-2.html index d606eb79..af3f76b3 100644 --- a/html/adminmanual-2.html +++ b/html/adminmanual-2.html @@ -2,19 +2,132 @@
-In earlier versions of Spider, all the processes were Perl scripts. This was fine but with a lot of users your computer memory would soon be used up. To combat this a new client was written in "C". This client only works for incoming connects at the moment. Before you can use it though it has to be "made". CD to /spider/src and type make. You should see the output on your screen and hopefully now have a small C program called client. Leave it in this directory. +
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. +
+
+
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. +
+
+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.