html/adminmanual-5.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
   2 <HTML>
   3 <HEAD>
   4  <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
   5  <TITLE>The DXSpider Installation and Administration Manual : Filtering</TITLE>
   6  <LINK HREF="adminmanual-6.html" REL=next>
   7  <LINK HREF="adminmanual-4.html" REL=previous>
   8  <LINK HREF="adminmanual.html#toc5" REL=contents>
   9 </HEAD>
  10 <BODY>
  11 <A HREF="adminmanual-6.html">Next</A>
  12 <A HREF="adminmanual-4.html">Previous</A>
  13 <A HREF="adminmanual.html#toc5">Contents</A>
  14 <HR>
  15 <H2><A NAME="s5">5. Filtering</A></H2>
  16
  17 <P>Filters can be set for spots, announcements and WWV.  You will find the directories for these under /spider/filter.  You will find some example in the directories with the suffix <EM>.issue</EM>.  There are two types of filter, one for incoming information and one for outgoing information. Outgoing filters are in the form <EM>CALLSIGN.pl</EM> and incoming filters are in the form <EM>in_CALLSIGN.pl</EM>.  Filters can be set for both nodes and users.
  18 <P>
  19 <H2><A NAME="ss5.1">5.1 Spots</A>
  20 </H2>
  21
  22 <P>All filters work in basically the same way.  There are several elements delimited by commas.  I will use the spot filter as an example ....
  23 <P>
  24 <P>The elements of the Spot filter are ....
  25 <P>
  26 <BLOCKQUOTE><CODE>
  27 <PRE>
  28 [action, field_no, sort, possible_values, hops]
  29 </PRE>
  30 </CODE></BLOCKQUOTE>
  31 <P>
  32 <P>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).
  33 <P>
  34 <P>The second element is the field_no.  There are 13 possiblities to choose from here ....
  35 <P>
  36 <BLOCKQUOTE><CODE>
  37 <PRE>
  38       0 = frequency
  39       1 = call
  40       2 = date in unix format
  41       3 = comment
  42       4 = spotter
  43       5 = spotted dxcc country
  44       6 = spotter's dxcc country
  45       7 = origin
  46       8 = spotted itu
  47       9 = spotted cq
  48       10 = spotter's itu
  49       11 = spotter's cq
  50       12 = callsign of the channel on which the spot has appeared
  51 </PRE>
  52 </CODE></BLOCKQUOTE>
  53 <P>
  54 <P>The third element tells us what to expect in the fourth element.  There are 4 possibilities ....
  55 <P>
  56 <BLOCKQUOTE><CODE>
  57 <PRE>
  58      n - numeric list of numbers e.g. [ 1,2,3 ]
  59      r - ranges of pairs of numbers e.g. between 2 and 4 or 10 to 17 - [ 2,4, 10,17 ]
  60      a - an alphanumeric regex
  61      d - the default rule
  62 </PRE>
  63 </CODE></BLOCKQUOTE>
  64 <P>
  65 <P>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.
  66 <P>
  67 <P>So, let's look at an example spot filter.  It does not matter in the example who the filter is to be used for.
  68 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.
  69 <P>
  70 <BLOCKQUOTE><CODE>
  71 <PRE>
  72 $in = [
  73   [ 0, 4, 'a', '^(K|N|A|W|VE|VA|J)'],  # 0 = drop, 'a' = alphanumeric
  74   [ 1, 0, 'd', 0, 1 ],                 # 1 = want, 'd' = everything else
  75                      ];
  76 </PRE>
  77 </CODE></BLOCKQUOTE>
  78 <P>
  79 <P>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.
  80 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.
  81 <P>
  82 <P>What this line does is tell the program to drop any spots posted by anyone in the USA, Canada or Japan.
  83 <P>
  84 <P>The second line is the default rule for anything else.  The "d" tells us this and the line simply reads... accept anything else.
  85 <P>
  86 <P>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 ....
  87 <P>
  88 <BLOCKQUOTE><CODE>
  89 <PRE>
  90 [ 0,0,'r',[1800.0, 2000.0], 1],
  91 [ 0,0,'r',[10100.0, 10150.0], 1],
  92 [ 0,0,'r',[14000.0, 14350.0], 1],
  93 [ 0,0,'r',[18000.0, 18200.0], 1],
  94 </PRE>
  95 </CODE></BLOCKQUOTE>
  96 <P>
  97 <P>But the line below achieves the same thing and is more efficient ....
  98 <P>
  99 <BLOCKQUOTE><CODE>
 100 <PRE>
 101     [
 102       1800.0, 2000.0,         # top band
 103       10100.0, 10150.0,       # WARC
 104       14000.0, 14350.0,       # 20m
 105       18000.0, 18200.0,       # WARC
 106     [ ,1 ],
 107 </PRE>
 108 </CODE></BLOCKQUOTE>
 109 <P>
 110 <P>
 111 <H2><A NAME="ss5.2">5.2 Announcements</A>
 112 </H2>
 113
 114 <P>
 115 <BLOCKQUOTE><CODE>
 116 <PRE>
 117
 118 # This is an example announce or filter allowing only West EU announces
 119 #
 120 # The element list is:-
 121 # 0 - callsign of announcer
 122 # 1 - destination * = all, &lt;callsign> = routed to the node
 123 # 2 - text
 124 # 3 - * - sysop, &lt;some text> - special list eg 6MUK, ' ', normal announce
 125 # 4 - origin
 126 # 5 - 0 - announce, 1 - wx
 127 # 6 - channel callsign (the interface from which this spot came)
 128
 129 $in = [
 130         [ 1, 0, 'a', '^(P[ABCDE]|DK0WCY|G|M|2|EI|F|ON)' ],
 131         [ 0, 0, 'd', 0 ]
 132 ];
 133 </PRE>
 134 </CODE></BLOCKQUOTE>
 135 <P>In this example, only the prefixes listed will be allowed.  It is possible to be quite specific.  The Dutch prefix "P" is followed by several secondary identifiers which are allowed.  So, in the example, "PA" or "PE" would be ok but not "PG".  It is even possible to allow information from a single callsign.  In the example this is DK0WCY, to allow the posting of his Aurora Beacon.
 136 <P>
 137 <H2><A NAME="ss5.3">5.3 WWV</A>
 138 </H2>
 139
 140 <P>
 141 <BLOCKQUOTE><CODE>
 142 <PRE>
 143
 144 # This is an example WWV filter
 145 #
 146 # The element list is:-
 147 # 0 - nominal unix date of spot (ie the day + hour:13)
 148 # 1 - the hour
 149 # 2 - SFI
 150 # 3 - K
 151 # 4 - I
 152 # 5 - text
 153 # 6 - spotter
 154 # 7 - origin
 155 # 8 - incoming interface callsign
 156
 157 # this one doesn't filter, it just sets the hop count to 6 and is
 158 # used mainly just to override any isolation from WWV coming from
 159 # the internet.
 160
 161 $in = [
 162         [ 1, 0, 'd', 0, 6 ]
 163 ];
 164 </PRE>
 165 </CODE></BLOCKQUOTE>
 166 <P>
 167 <P>It should be noted that the filter will start to be used only once a user/node has logged out and back in again.
 168 <P>I am not going to spend any more time on these filters now as they will become more "comprehensive" in the near future.
 169 <P>
 170 <H2><A NAME="ss5.4">5.4 Filtering Mail</A>
 171 </H2>
 172
 173 <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 ....
 174 <P>
 175 <BLOCKQUOTE><CODE>
 176 <PRE>
 177
 178 # the list of regexes for messages that we won't store having
 179 # received them (bear in mind that we must receive them fully before
 180 # we can bin them)
 181
 182
 183 # The format of each line is as follows
 184
 185 #     type      source             pattern
 186 #     P/B/F     T/F/O/S            regex
 187
 188 # type: P - private, B - bulletin (msg), F - file (ak1a bull)
 189 # source: T - to field, F - from field,  O - origin, S - subject
 190 # pattern: a perl regex on the field requested
 191
 192 # Currently only type B and P msgs are affected by this code.
 193 #
 194 # The list is read from the top down, the first pattern that matches
 195 # causes the action to be taken.
 196
 197 # The pattern can be undef or 0 in which case it will always be selected
 198 # for the action specified
 199
 200
 201
 202 package DXMsg;
 203
 204 @badmsg = (
 205 'B',    'T',    'SALE',
 206 'B',    'T',    'WANTED',
 207 'B',    'S',    'WANTED',
 208 'B',    'S',    'SALE',
 209 'B',    'S',    'WTB',
 210 'B',    'S',    'WTS',
 211 'B',    'T',    'FS',
 212 );
 213 </PRE>
 214 </CODE></BLOCKQUOTE>
 215 <P>
 216 <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.
 217 <P>
 218 <H2><A NAME="ss5.5">5.5 Filtering DX callouts</A>
 219 </H2>
 220
 221 <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 ....
 222 <P>
 223 <BLOCKQUOTE><CODE>
 224 <PRE>
 225
 226 # the list of dx spot addresses that we don't store and don't pass on
 227
 228
 229 package DXProt;
 230
 231 @baddx = qw
 232
 233  FROG
 234  SALE
 235  FORSALE
 236  WANTED
 237  P1RATE
 238  PIRATE
 239  TEST
 240  DXTEST
 241  NIL
 242  NOCALL
 243 );
 244 </PRE>
 245 </CODE></BLOCKQUOTE>
 246 <P>
 247 <P>Again, this is simply a list of names we do not want to see in the spotted field of a DX callout.
 248 <P>
 249 <P>
 250 <HR>
 251 <A HREF="adminmanual-6.html">Next</A>
 252 <A HREF="adminmanual-4.html">Previous</A>
 253 <A HREF="adminmanual.html#toc5">Contents</A>
 254 </BODY>
 255 </HTML>