<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>The DXSpider Installation and Administration Manual : Sysop commands</TITLE>
+ <TITLE>The DXSpider Installation and Administration Manual : Filtering (New Style v1.45 and later)</TITLE>
+ <LINK HREF="adminmanual-8.html" REL=next>
<LINK HREF="adminmanual-6.html" REL=previous>
<LINK HREF="adminmanual.html#toc7" REL=contents>
+<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
</HEAD>
<BODY>
-Next
+<A HREF="adminmanual-8.html">Next</A>
<A HREF="adminmanual-6.html">Previous</A>
<A HREF="adminmanual.html#toc7">Contents</A>
<HR>
-<H2><A NAME="s7">7. Sysop commands</A></H2>
+<H2><A NAME="s7">7. Filtering (New Style v1.45 and later)</A></H2>
-<P>Most maintenance tasks are automatic but there are some commands that are useful for a sysop. These are listed below in alphabetical order. The number in brackets following the command name is the permissions level needed to use the command.
-<P>
-<H2><A NAME="ss7.1">7.1 announce sysop (5)</A>
-</H2>
-
-<P><CODE><B>announce sysop <text></B></CODE>
-<P>
-<P>Send an announcement to Sysops only
-<P>
-<H2><A NAME="ss7.2">7.2 connect (5) </A>
+<H2><A NAME="ss7.1">7.1 General filter rules</A>
</H2>
-<P><CODE><B>connect <callsign></B> Start a connection to another DX Cluster</CODE>
+<P>Upto v1.44 it was not possible for the user to set their own filters. From
+v1.45 though that has all changed. It is now possible to set filters for just
+about anything you wish. If you have just updated from an older version of
+DXSpider you will need to update your new filters. You do not need to do
+anything with your old filters, they will be renamed as you update.
<P>
-<P>Start a connection process that will culminate in a new connection to the
-DX cluster <callsign>. This process creates a new 'client' process which will
-use the script in /spider/connect/<callsign> to effect the 'chat' exchange
-necessary to traverse the network(s) to logon to the cluster <callsign>.
+<P>There are 3 basic commands involved in setting and manipulating filters. These
+are <EM>accept</EM>, <EM>reject</EM> and <EM>clear</EM>. First we will look
+generally at filtering. There are a number of things you can filter in the
+DXSpider system. They all use the same general mechanism.
<P>
-<P>
-<H2><A NAME="ss7.3">7.3 catch (9) </A>
-</H2>
-
-<P><CODE><B><node_call> All [<msgno> ...]</B> Mark a message as sent</CODE>
-<P>
-<P>When you send messages the fact that you have forwarded it to another node
-is remembered so that it isn't sent again. When you have a new partner
-node and you add their callsign to your /spider/msg/forward.pl file, all
-outstanding non-private messages will be forwarded to them. This may well
-be ALL the non-private messages. You can prevent this by using these
-commmands:-
-<P>catch GB7DJK all
-catch GB7DJK 300 301 302 303
-<P>and to undo what you have just done:-
-<P>uncatch GB7DJK all
-uncatch GB7DJK 300 301 302 303
-<P>which will arrange for them to be forward candidates again.
-<P>
-<H2><A NAME="ss7.4">7.4 dbcreate (9)</A>
-</H2>
-
-<P><CODE><B>dbcreate <name></B> Create a database entry<BR>
-<B>dbcreate <name> chain <name> [<name>..]</B> Create a chained database entry<BR>
-<B>dbcreate <name> remote <node></B> Create a remote database entry<BR></CODE>
-<P>
-<P>DBCREATE allows you to define a database in the system. It doesn't actually
-create anything, just defines it.
-<P>The databases that are created are simple DB_File hash databases, they are
-therefore already 'indexed'.
-<P>You can define a local database with the first form of the command eg:
-<P>DBCREATE oblast
-<P>You can also chain databases with the addition of the 'chain' keyword.
-This will search each database one after the other. A typical example
-is:
-<P>DBCREATE sdx_qsl chain sql_ad
-<P>No checking is done to see if the any of the chained databases exist, in
-fact it is usually better to do the above statement first then do each of
-the chained databases.
-<P>Databases can exist offsite. To define a database that lives on another
-node do:
-<P>DBCREATE buckmaster remote gb7dxc
-<P>Remote databases cannot be chained; however, the last database in a
-a chain can be a remote database eg:
-<P>DBCREATE qsl chain gb7dxc
-<P>To see what databases have been defined do:
-<P>DBAVAIL (or it will have been aliased to SHOW/COMMAND)
-<P>It would be normal for you to add an entry into your local Aliases file
-to allow people to use the 'SHOW/<dbname>' style syntax. So you would
-need to add a line like:-
+<P>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 ...
<P>
<BLOCKQUOTE><CODE>
<PRE>
- 's' => [
- ..
- ..
- '^sh\w*/buc', 'dbshow buckmaster', 'dbshow',
- ..
- ..
- ],
+
+accept/spots .....
+reject/spots .....
</PRE>
</CODE></BLOCKQUOTE>
-<P>to allow
-<P>SH/BUCK g1tlh
-<P>to work as they may be used to.
-<P>See DBIMPORT for the importing of existing AK1A format data to databases.
-See DBSHOW for generic database enquiry
-<P>
-<H2><A NAME="ss7.5">7.5 dbimport (9)</A>
-</H2>
-
-<P><CODE><B>dbimport <dbname></B> Import AK1A data into a database</CODE>
-<P>
-<P>If you want to import or update data in bulk to a database you can use
-this command. It will either create or update entries into an existing
-database. For example:-
-<P>DBIMPORT oblast /tmp/OBLAST.FUL
-<P>will import the standard OBLAST database that comes with AK1A into the
-oblast database held locally.
-<P>
-<H2><A NAME="ss7.6">7.6 dbremove (9)</A>
-</H2>
-
-<P><CODE><B>dbremove <dbname></B> Delete a database</CODE>
-<P>
-<P>DBREMOVE will completely remove a database entry and also delete any data
-file that is associated with it.
-<P>There is no warning, no comeback, no safety net.
-<P>For example:
-<P>DBREMOVE oblast
-<P>will remove the oblast database from the system and it will also remove
-the associated datafile.
-<P>I repeat:
-<P>There is no warning, no comeback, no safety net.
-<P>You have been warned.
-<P>
-<H2><A NAME="ss7.7">7.7 debug (9)</A>
-</H2>
-
-<P><CODE><B>debug</B> Set the cluster program into debug mode</CODE>
-<P>
-<P>Executing this command will only have an effect if you are running the cluster
-in debug mode i.e.
+<P>where ..... are the specific commands for that type of filter. There are filters
+for spots, wwv, announce, wcy and (for sysops) connects. See each different
+accept or reject command reference for more details.
+<P>There is also a command to clear out one or more lines in a filter. They are ...
<P>
<BLOCKQUOTE><CODE>
<PRE>
- perl -d cluster.pl
+clear/spots 1
+clear/spots all
</PRE>
</CODE></BLOCKQUOTE>
-<P>It will interrupt the cluster just after the debug command has finished.
-<P>
-<H2><A NAME="ss7.8">7.8 directory (5)</A>
-</H2>
-
-<P>Works just like the user command except that sysops can see ALL messages.
-<P>
-<H2><A NAME="ss7.9">7.9 disconnect (8)</A>
-</H2>
-
-<P><CODE><B>disconnect <call> [<call> ...]</B> Disconnect a user or node</CODE>
-<P>
-<P>Disconnect any <call> connected locally
+<P>There is clear/xxxx command for each type of filter.
<P>
-<H2><A NAME="ss7.10">7.10 export (9)</A>
-</H2>
-
-<P><CODE><B>export <msgno> <filename></B> Export a message to a file</CODE>
-<P>
-<P>Export a message to a file. This command can only be executed on a local
-console with a fully privileged user. The file produced will be in a form
-ready to be imported back into the cluster by placing it in the import
-directory (/spider/msg/import).
-<P>This command cannot overwrite an existing file. This is to provide some
-measure of security. Any files written will owned by the same user as the
-main cluster, otherwise you can put the new files anywhere the cluster can
-access. For example:-
-<P>EXPORT 2345 /tmp/a
-<P>
-<H2><A NAME="ss7.11">7.11 forward/opername (1)</A>
-</H2>
-
-<P><CODE><B>forward/opername <call></B> Send out information on this <call> to all clusters</CODE>
-<P>
-<P>This command sends out any information held in the user file which can
-be broadcast in PC41 protocol packets. This information is Name, QTH, Location
-and Homenode. PC41s are only sent for the information that is available.
-<P>
-<H2><A NAME="ss7.12">7.12 init (5)</A>
-</H2>
-
-<P><CODE><B>init <node call></B> Re-initialise a link to an AK1A compatible node</CODE>
-<P>
-<P>This command attempts to re-initialise a link to a (usually) AK1A node
-that has got confused, usually by a protocol loop of some kind. It may
-work - but you usually will be better off simply disconnecting it (or
-better, if it is a real AK1A node, doing an RCMD <node> DISC/F <your
-node>).
-<P>Best of luck - you will need it.
-<P>
-<H2><A NAME="ss7.13">7.13 kill (5)</A>
-</H2>
-
-<P><CODE><B>kill <msgno> [<msgno> ...]</B> Remove or erase a message from the system<BR>
-<B>kill from <call></B> Remove all messages from a callsign<BR>
-<B>kill to <call></B> Remove all messages to a callsign<BR></CODE>
-<P>
-<P>You can get rid of any message to or originating from your callsign using
-this command. You can remove more than one message at a time.
-<P>As a sysop you can kill any message on the system.
-<P>
-<H2><A NAME="ss7.14">7.14 kill full (5)</A>
-<CODE><B>kill full <msgno> [<msgno>]</B> Delete a message from the whole cluster</CODE></H2>
-
-<P>Delete a message (usually a 'bulletin') from the whole cluster system.
-<P>This uses the subject field, so any messages that have exactly the same subject
-will be deleted. Beware!
-<P>
-<H2><A NAME="ss7.15">7.15 load/aliases (9)</A>
-</H2>
-
-<P><CODE><B>load/aliases</B> Reload the command alias table</CODE>
-<P>
-<P>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.
-<P>
-<H2><A NAME="ss7.16">7.16 load/bands (9)</A>
-</H2>
-
-<P><CODE><B>load/bands</B> Reload the band limits table</CODE>
-<P>
-<P>Reload the /spider/data/bands.pl file if you have changed it manually whilst
-the cluster is running.
-<P>
-<H2><A NAME="ss7.17">7.17 load/cmd_cache (9)</A>
-</H2>
-
-<P><CODE><B>load/cmd_cache</B> Reload the automatic command cache</CODE>
-<P>
-<P>Normally, if you change a command file in the cmd or local_cmd tree it will
-automatially be picked up by the cluster program. Sometimes it can get confused
-if you are doing a lot of moving commands about or delete a command in the
-local_cmd tree and want to use the normal one again. Execute this command to
-reset everything back to the state it was just after a cluster restart.
-<P>
-<H2><A NAME="ss7.18">7.18 load/messages (9)</A>
-</H2>
-
-<P><CODE><B>load/messages</B> Reload the system messages file</CODE>
-<P>
-<P>If you change the /spider/perl/Messages file (usually whilst fiddling/writing ne
-commands) you can have them take effect during a cluster session by executing this
-command. You need to do this if get something like :-
-<P>unknown message 'xxxx' in lang 'en'
-<P>
-<H2><A NAME="ss7.19">7.19 load/prefixes (9)</A>
-</H2>
-
-<P><CODE><B>load/prefixes</B> Reload the prefix table</CODE>
-<P>
-<P>Reload the /spider/data/prefix_data.pl file if you have changed it manually whilst
-the cluster is running.
-<P>
-<H2><A NAME="ss7.20">7.20 merge (5)</A>
-</H2>
-
-<P><CODE><B>merge <node> [<no spots>/<no wwv>]</B> Ask for the latest spots and WWV</CODE>
-<P>
-<P>MERGE allows you to bring your spot and wwv database up to date. By default
-it will request the last 10 spots and 5 WWVs from the node you select. The
-node must be connected locally.
-<P>You can request any number of spots or wwv and although they will be appended
-to your databases they will not duplicate any that have recently been added
-(the last 2 days for spots and last month for WWV data).
-<P>
-<H2><A NAME="ss7.21">7.21 msg (9)</A>
-</H2>
-
-<P><CODE><B>msg <cmd> <msgno> [data ...]</B> Alter various message parameters</CODE>
-<P>
-<P>Alter message parameters like To, From, Subject, whether private or bulletin
-or return receipt (RR) is required or whether to keep this message from timing
-out.
+<P>and you can check that your filters have worked by the command ...
<P>
<BLOCKQUOTE><CODE>
<PRE>
- MSG TO <msgno> <call> - change TO callsign to <call>
- MSG FRom <msgno> <call> - change FROM callsign to <call>
- MSG PRrivate <msgno> - set private flag
- MSG NOPRrivate <msgno> - unset private flag
- MSG RR <msgno> - set RR flag
- MSG NORR <msgno> - unset RR flag
- MSG KEep <msgno> - set the keep flag (message won't be deleted ever)
- MSG NOKEep <msgno> - unset the keep flag
- MSG SUbject <msgno> <new> - change the subject to <new>
- MSG WAittime <msgno> - remove any waitting time for this message
- MSG NOREad <msgno> - mark message as unread
- MSG REad <msgno> - mark message as read
- MSG QUeue - queue any outstanding bulletins
- MSG QUeue 1 - queue any outstanding private messages
+
+show/filter
</PRE>
</CODE></BLOCKQUOTE>
-<P>You can look at the status of a message by using:-
-<P>STAT/MSG <msgno>
-<P>This will display more information on the message than DIR does.
-<P>
-<H2><A NAME="ss7.22">7.22 pc (8)</A>
-</H2>
-
-<P><CODE><B>pc <call> <text></B> Send text (eg PC Protocol) to <call></CODE>
-<P>
-<P>Send some arbitrary text to a locally connected callsign. No processing is done on
-the text. This command allows you to send PC Protocol to unstick things if problems
-arise (messages get stuck etc). eg:-
-<P>pc gb7djk PC33^GB7TLH^GB7DJK^400^
-<P>You can also use in the same way as a talk command to a connected user but
-without any processing, added of "from <blah> to <blah>" or whatever.
-<P>pc G1TLH Try doing that properly!!!
-<P>
-<H2><A NAME="ss7.23">7.23 ping (1)</A>
-</H2>
-
-<P><CODE><B>ping <node></B> Send a ping command to another cluster node</CODE>
-<P>
-<P>This command is used to estimate the quality of the link to another cluster.
-The time returned is the length of time taken for a PC51 to go to another
-cluster and be returned.
-<P>Any visible cluster node can be PINGed.
-<P>
-<H2><A NAME="ss7.24">7.24 rcmd (1)</A>
-</H2>
-
-<P><CODE><B>rcmd <node call> <cmd></B> Send a command to another DX cluster</CODE>
-<P>
-<P>This command allows you to send nearly any command to another DX Cluster
-node that is connected to the system.
-<P>Whether you get any output is dependant on a) whether the other system knows
-that the node callsign of this cluster is in fact a node b) whether the
-other system is allowing RCMDs from this node and c) whether you have
-permission to send this command at all.
-<P>
-<H2><A NAME="ss7.25">7.25 read (5)</A>
-</H2>
-
-<P><CODE><B>read <msgno></B> Read a message on the system</CODE>
-<P>
-<P>As a sysop you may read any message on the system
-<P>
-<H2><A NAME="ss7.26">7.26 set/debug (9)</A>
-</H2>
-
-<P><CODE><B>set/debug <name></B>Add a debug level to the debug set</CODE>
-<P>
-<P>You can remove this level with unset/debug <name>
-<P>
-<H2><A NAME="ss7.27">7.27 set/isolate (9)</A>
-</H2>
-
-<P><CODE><B>set/isolate <node call></B> Isolate a node from the rest of the network</CODE>
-<P>
-<P>Connect a node to your system in such a way that you are a full protocol
-member of its network and can see all spots on it, but nothing either leaks
-out from it nor goes back into from the rest of the nodes connected to you.
-<P>You can potentially connect several nodes in this way.
-<P>You can see which nodes are isolated with the show/isolate (1) command.
-<P>You can remove the isolation with the command unset/isolate.
-<P>
-<H2><A NAME="ss7.28">7.28 set/sys_location (9)</A>
-</H2>
-
-<P><CODE><B>set/sys_location <lat & long></B>Set your cluster latitude and longitude</CODE>
<P>
-<P>In order to get accurate headings and such like you must tell the system
-what your latitude and longitude is. If you have not yet done a SET/QRA
-then this command will set your QRA locator for you. For example:-
-<P>SET/LOCATION 52 22 N 0 57 E
+<P>For now we are going to use spots for the examples, but you can apply the same
+principles to all types of filter.
<P>
-<H2><A NAME="ss7.29">7.29 set/lockout (9)</A>
+<H2><A NAME="ss7.2">7.2 Types of filter</A>
</H2>
-<P><CODE><B>set/lockout <call></B>Stop a callsign connecting to the cluster</CODE>
+<P>There are two main types of filter, <EM>accept</EM> or <EM>reject</EM>. You
+can use either to achieve the result you want dependent on your own preference
+and which is more simple to do. It is pointless writing 8 lines of reject
+filters when 1 accept filter would do the same thing! Each filter has 10
+lines (of any length) which are tried in order. If a line matches then the
+action you have specified is taken (ie reject means ignore it and accept
+means take it)
<P>
-<P>You can show who is locked out with the show/lockout (9) command.
-<P>To allow the user to connect again, use the command unset/lockout
-<P>
-<H2><A NAME="ss7.30">7.30 set/node (9)</A>
-</H2>
-
-<P><CODE><B>set/node <call> [<call> ...]</B>Make the callsign an AK1A cluster</CODE>
-<P>
-<P>Tell the system that the call(s) are to be treated as AK1A cluster and
-fed PC Protocol rather normal user commands.
-<P>From version 1.41 you can also set the following types of cluster
+<P>If you specify reject filters, then any lines that arrive that match the filter
+will be dumped but all else will be accepted. If you use an accept filter,
+then ONLY the lines in the filter will be accepted and all else will be dumped.
+For example if you have a single line <EM>accept</EM> filter ...
<P>
+<BLOCKQUOTE><CODE>
<PRE>
-set/spider
-set/dxnet
-set/clx
-set/arcluster
+accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
</PRE>
-<P>To see what your nodes are set to, use the show/nodes command.
-<P>
-<H2><A NAME="ss7.31">7.31 set/obscount (9)</A>
-</H2>
-
-<P><CODE><B>set/obscount <count> <node call></B> Set the 'pump-up' obscelence counter</CODE>
+</CODE></BLOCKQUOTE>
+<P>then you will <EM>ONLY</EM> get VHF spots <EM>from</EM> or <EM>to</EM> CQ zones
+14, 15 and 16.
<P>
-<P>From version 1.35 onwards neighbouring nodes are pinged at regular intervals (see
-SET/PINGINTERVAL), usually 300 seconds or 5 minutes. There is a 'pump-up'
-counter which is decremented on every outgoing ping and then reset to
-the 'obscount' value on every incoming ping. The default value of this
-parameter is 2.
-<P>What this means is that a neighbouring node will be pinged twice at
-(default) 300 second intervals and if no reply has been heard just before
-what would be the third attempt, that node is disconnected.
-<P>If a ping is heard then the obscount is reset to the full value. Using
-default values, if a node has not responded to a ping within 15 minutes,
-it is disconnected.
+<P>If you set a reject filter like this ...
<P>
-<H2><A NAME="ss7.32">7.32 set/pinginterval (9)</A>
-</H2>
-
-<P><CODE><B>set/pinginterval <time> <node call></B> Set the ping time to neighbouring nodes</CODE>
+<BLOCKQUOTE><CODE>
+<PRE>
+reject/spots on hf/cw
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Then you will get everything <EM>EXCEPT</EM> HF CW spots. You could make this
+single filter even more flexible. For example, if you are interested in IOTA
+and will work it even on CW even though normally you are not interested in
+CW, then you could say ...
<P>
-<P>As from version 1.35 all neighbouring nodes are pinged at regular intervals
-in order to determine the rolling quality of the link and, in future, to
-affect routing decisions. The default interval is 300 secs or 5 minutes.
-<P>You can use this command to set a different interval. Please don't.
-<P>But if you do the value you enter is treated as minutes up 60 and seconds
-for numbers greater than that.
-<P>This is used also to help determine when a link is down at the far end
-(as certain cluster software doesn't always notice), see SET/OBSCOUNT
-for more information.
+<BLOCKQUOTE><CODE>
+<PRE>
+reject/spots on hf/cw and not info iota
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>But in that case you might only be interested in iota and say:-
<P>
-<H2><A NAME="ss7.33">7.33 set/privilege (9)</A>
-</H2>
-
-<P><CODE><B>set/privilege <n> <call> [<call> ...]</B> Set the privilege level on a call</CODE>
+<BLOCKQUOTE><CODE>
+<PRE>
+accept/spots not on hf/cw or info iota
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>which achieves exactly the same thing. You should choose one or the other
+until you are comfortable with the way it works. You can mix them if you
+wish (actually you can have an accept AND a reject on the same line) but
+don't attempt this until you are sure you know what you are doing!
<P>
-<P>Set the privilege level on a callsign. The privilege levels that pertain
-to commands are as default:-
+<P>You can arrange your filter lines into logical units, either for your own
+understanding or simply convenience. Here is an example ...
<P>
<BLOCKQUOTE><CODE>
<PRE>
- 0 - normal user
- 1 - allow remote nodes normal user RCMDs
- 5 - various privileged commands (including shutdown, but not disc-
- connect), the normal level for another node.
- 8 - more privileged commands (including disconnect)
- 9 - local sysop privilege. DO NOT SET ANY REMOTE USER OR NODE TO THIS
- LEVEL.
+reject/spots 1 on hf/cw
+reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)
</PRE>
</CODE></BLOCKQUOTE>
-<P>If you are a sysop and you come in as a normal user on a remote connection
-your privilege will automatically be set to 0.
+<P>What this does is to ignore all HF CW spots and also rejects any spots on VHF
+which don't either originate or spot someone in Europe.
<P>
-<H2><A NAME="ss7.34">7.34 set/password (9)</A>
-</H2>
-
-<P><CODE><B>set/password <callsign> <string></B> Set a users password</CODE>
+<P>This is an example where you would use a line number (1 and 2 in this case), if
+you leave the digit out, the system assumes '1'. Digits '0'-'9' are available.
+This make it easier to see just what filters you have set. It also makes it
+more simple to remove individual filters, during a contest for example.
<P>
-<P>The password for a user can only be set by a full sysop. The string
-can contain any characters but any spaces are removed (you can type in
-spaces - but they won't appear in the password). You can see the
-result with STAT/USER. The password is the usual 30 character baycom
-type password.
+<P>You will notice in the above example that the second line has brackets. Look
+at the line logically. You can see there are 2 separate sections to it. We
+are saying reject spots that are VHF or above <EM>APART</EM> from those in
+zones 14, 15 and 16 (either spotted there or originated there). If you did
+not have the brackets to separate the 2 sections, then Spider would read it
+logically from the front and see a different expression entirely ...
<P>
-<H2><A NAME="ss7.35">7.35 set/sys_qra (9)</A>
-</H2>
-
-<P><CODE><B>set/sys_qra <locator></B> Set your cluster QRA locator</CODE>
-<P>
-<H2><A NAME="ss7.36">7.36 show program (5)</A>
-</H2>
-
-<P><CODE><B>show/program</B> Show the locations of all the included program modules</CODE>
+<BLOCKQUOTE><CODE>
+<PRE>
+(on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The simple way to remember this is, if you use OR - use brackets. Whilst we are
+here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'.
+<P>As mentioned earlier, setting several filters can be more flexible than
+simply setting one complex one. Doing it in this way means that if you want
+to alter your filter you can just redefine or remove one or more lines of it or
+one line. For example ...
<P>
-<P>Show the name and location where every program module was load from. This
-is useful for checking where you think you have loaded a .pm file from.
+<BLOCKQUOTE><CODE>
+<PRE>
+reject/spots 1 on hf/ssb
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>would redefine our earlier example, or
<P>
-<H2><A NAME="ss7.37">7.37 shutdown (5)</A>
-</H2>
-
-<P><CODE><B>shutdown</B>Shutdown the cluster</CODE>
+<BLOCKQUOTE><CODE>
+<PRE>
+clear/spots 1
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>To remove all the filter lines in the spot filter ...
<P>
-<P>Shutdown the cluster and disconnect all the users. If you have Spider
-set to respawn in /etc/inittab it will of course restart.
+<BLOCKQUOTE><CODE>
+<PRE>
+clear/spots all
+</PRE>
+</CODE></BLOCKQUOTE>
<P>
-<H2><A NAME="ss7.38">7.38 stat/db (5)</A>
+<H2><A NAME="ss7.3">7.3 Filter options</A>
</H2>
-<P><CODE><B>stat/db <dbname></B> Show the status of a database</CODE>
+<P>You can filter in several different ways. The options are listed in the
+various helpfiles for accept, reject and filter.
<P>
-<P>Show the internal status of a database descriptor.
-<P>Depending on your privilege level you will see more or less information.
-This command is unlikely to be of much use to anyone other than a sysop.
-<P>
-<H2><A NAME="ss7.39">7.39 stat/channel (5)</A>
+<H2><A NAME="ss7.4">7.4 Default filters</A>
</H2>
-<P><CODE><B>stat/channel <callsign></B> Show the status of a channel on the cluster</CODE>
+<P>Sometimes all that is needed is a general rule for node connects. This can
+be done with a node_default filter. This rule will always be followed, even
+if the link is isolated, unless another filter is set specifically. Default
+rules can be set for nodes and users. They can be set for spots, announces,
+WWV and WCY. They can also be used for hops. An example might look like
+this ...
<P>
-<P>Show the internal status of the channel object either for the channel that
-you are on or else for the callsign that you asked for.
-<P>Only the fields that are defined (in perl term) will be displayed.
+<BLOCKQUOTE><CODE>
+<PRE>
+accept/spot node_default by_zone 14,15,16,20,33
+set/hops node_default spot 50
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This filter is for spots only, you could set others for announce, WWV and WCY.
+This filter would work for ALL nodes unless a specific filter is written to
+override it for a particular node. You can also set a user_default should
+you require. It is important to note that default filters should be
+considered to be "connected". By this I mean that should you override the
+default filter for spots, you need to add a rule for the hops for spots also.
<P>
-<H2><A NAME="ss7.40">7.40 stat/msg (5)</A>
+<H2><A NAME="ss7.5">7.5 Advanced filtering</A>
</H2>
-<P><CODE><B>stat/msg <msgno></B> Show the status of a message</CODE>
+<P>Once you are happy with the results you get, you may like to experiment.
<P>
-<P>This command shows the internal status of a message and includes information
-such as to whom it has been forwarded, its size, origin etc etc.
-<P>
-<H2><A NAME="ss7.41">7.41 stat/user (5)</A>
-</H2>
-
-<P><CODE><B>stat/user <callsign></B> Show the full status of a user</CODE>
+<P>The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU
+can be written with a mixed filter, for example ...
<P>
-<P>Shows the full contents of a user record including all the secret flags
-and stuff.
-<P>Only the fields that are defined (in perl term) will be displayed.
+<BLOCKQUOTE><CODE>
+<PRE>
+rej/spot on hf/cw
+acc/spot on 0/30000
+acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Note that the first filter has not been specified with a number. This will
+automatically be assumed to be number 1. In this case, we have said <EM>reject all
+HF spots in the CW section of the bands but accept all others at HF. Also
+accept anything in VHF and above spotted in or by operators in the zones
+14, 15 and 16</EM>. Each filter slot actually has a 'reject' slot and
+an 'accept' slot. The reject slot is executed BEFORE the accept slot.
<P>
+<P>It was mentioned earlier that after a reject test that doesn't match, the default
+for following tests is 'accept', the reverse is true for 'accept'. In the example
+what happens is that the reject is executed first, any non hf/cw spot is passed
+to the accept line, which lets through everything else on HF. The next filter line
+lets through just VHF/UHF spots from EU.
<P>
<P>
<HR>
-Next
+<A HREF="adminmanual-8.html">Next</A>
<A HREF="adminmanual-6.html">Previous</A>
<A HREF="adminmanual.html#toc7">Contents</A>
</BODY>
projects / spider.git / blobdiff