<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>The DXSpider Installation and Administration Manual : Hop control</TITLE>
+ <TITLE>The DXSpider Administration Manual v1.47: Other filters</TITLE>
<LINK HREF="adminmanual-5.html" REL=next>
<LINK HREF="adminmanual-3.html" REL=previous>
<LINK HREF="adminmanual.html#toc4" REL=contents>
+<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
</HEAD>
<BODY>
<A HREF="adminmanual-5.html">Next</A>
<A HREF="adminmanual-3.html">Previous</A>
<A HREF="adminmanual.html#toc4">Contents</A>
<HR>
-<H2><A NAME="s4">4. Hop control</A></H2>
+<H2><A NAME="s4">4. Other filters</A></H2>
-<P>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).
-<P>
-<H2><A NAME="ss4.1">4.1 Basic hop control</A>
+<H2><A NAME="ss4.1">4.1 Filtering Mail</A>
</H2>
-<P>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 ...
+<P>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 ....
<P>
<BLOCKQUOTE><CODE>
<PRE>
-#
-# hop table construction
-#
-package DXProt;
+# 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)
-# default hopcount to use
-$def_hopcount = 5;
-# some variable hop counts based on message type
-%hopcount =
+# 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
+
- 11 => 10,
- 16 => 10,
- 17 => 10,
- 19 => 10,
- 21 => 10,
-);
+package DXMsg;
-# the per node hop control thingy
-
-
-%nodehops =
-
- GB7ADX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-
- GB7UDX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
- GB7BAA => {
- 11 => 5,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-};
+@badmsg = (
+'B', 'T', 'SALE',
+'B', 'T', 'WANTED',
+'B', 'S', 'WANTED',
+'B', 'S', 'SALE',
+'B', 'S', 'WTB',
+'B', 'S', 'WTS',
+'B', 'T', 'FS',
+);
</PRE>
</CODE></BLOCKQUOTE>
<P>
-<P>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.
-<P>
-<P>You can alter this file at any time, including whilst the cluster is running. If you alter the file during runtime, the command <EM>load/hops</EM> will bring your changes into effect.
+<P>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.
<P>
-<H2><A NAME="ss4.2">4.2 Isolating networks</A>
+<H2><A NAME="ss4.2">4.2 Filtering DX callouts (Depricated)</A>
</H2>
-<P>It is possible to isolate networks from each other on a "gateway" node using the
-<EM>set/isolate <node_call></EM> command.
+<P><B><I>From version 1.47, this method is replaced by the command set/baddx</I></B>
+<P>
+<P>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 ....
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+
+# the list of dx spot addresses that we don't store and don't pass on
+
+
+package DXProt;
+
+@baddx = qw
+
+ FROG
+ SALE
+ FORSALE
+ WANTED
+ P1RATE
+ PIRATE
+ TEST
+ DXTEST
+ NIL
+ NOCALL
+);
+</PRE>
+</CODE></BLOCKQUOTE>
<P>
-<P>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.
+<P>Again, this is simply a list of names we do not want to see in the spotted
+field of a DX callout.
<P>
-<P>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.
<P>
-<P>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 ....
+<H2><A NAME="ss4.3">4.3 Filtering words from text fields in Announce, Talk and DX spots</A>
+</H2>
+
+<P>Create a file in /spider/data called <EM>badwords</EM>. The format is quite
+simple. Lines beginning with # are ignored so comments can be added. An
+example file is below ...
<P>
<BLOCKQUOTE><CODE>
<PRE>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+# Below is a list of words we do not wish to see on the cluster
+grunge grunged grunging
+splodge splodger splodging
+grince
+fluffle
</PRE>
</CODE></BLOCKQUOTE>
+<P>Multiple words can be used on the same line as shown. Obviously these
+are just examples :-)
<P>
-<P>There is a lot more on filtering in the next section.
+<P>You can reload the file from the cluster prompt as sysop with load/badwords.
<P>
<HR>
<A HREF="adminmanual-5.html">Next</A>
projects / spider.git / blobdiff