- For now we are going to use spots for the examples, but you can apply
- the same principles to all types of filter.
-
-
- 7\b7.\b.2\b2.\b. T\bTy\byp\bpe\bes\bs o\bof\bf f\bfi\bil\blt\bte\ber\br
-
- There are two main types of filter, _\ba_\bc_\bc_\be_\bp_\bt or _\br_\be_\bj_\be_\bc_\bt. 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)
-
-
- 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
- _\ba_\bc_\bc_\be_\bp_\bt filter ...
-
-
-
- accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
-
- then you will _\bO_\bN_\bL_\bY get VHF spots _\bf_\br_\bo_\bm or _\bt_\bo CQ zones 14, 15 and 16.
-
- If you set a reject filter like this ...
-
-
-
- reject/spots on hf/cw
-
-
-
-
- Then you will get everything _\bE_\bX_\bC_\bE_\bP_\bT 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 ...
-
-
-
- reject/spots on hf/cw and not info iota
-
-
-
-
- But in that case you might only be interested in iota and say:-
-
-
-
- accept/spots not on hf/cw or info iota
-
-
-
-
- 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!
-
-
- You can arrange your filter lines into logical units, either for your
- own understanding or simply convenience. Here is an example ...
-
-
-
- reject/spots 1 on hf/cw
- reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
-
- 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.
-
-
- 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.
-
-
- 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 _\bA_\bP_\bA_\bR_\bT 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 ...
- (on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16
-
-
-
-
- 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'.
-
- 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 ...
-
-
-
- reject/spots 1 on hf/ssb
-
-
-
-
- would redefine our earlier example, or
-
-
-
- clear/spots 1
-
-
-
-
- To remove all the filter lines in the spot filter ...
-
-
-
- clear/spots all
-
-
-
-
-
- 7\b7.\b.3\b3.\b. F\bFi\bil\blt\bte\ber\br o\bop\bpt\bti\bio\bon\bns\bs
-
- You can filter in several different ways. The options are listed in
- the various helpfiles for accept, reject and filter.
-
-
- 7\b7.\b.4\b4.\b. D\bDe\bef\bfa\bau\bul\blt\bt f\bfi\bil\blt\bte\ber\brs\bs
-
- 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 ...
-
-
-
- accept/spot node_default by_zone 14,15,16,20,33
- set/hops node_default spot 50
-
-
-
-
- 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.
-
-
- 7\b7.\b.5\b5.\b. A\bAd\bdv\bva\ban\bnc\bce\bed\bd f\bfi\bil\blt\bte\ber\bri\bin\bng\bg
-
- Once you are happy with the results you get, you may like to
- experiment.
-
-
- The previous example that filters hf/cw spots and accepts vhf/uhf
- spots from EU can be written with a mixed filter, for example ...
-
-
-
- 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)
-
-
-
-
- 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 _\br_\be_\bj_\be_\bc_\bt _\ba_\bl_\bl _\bH_\bF _\bs_\bp_\bo_\bt_\bs _\bi_\bn _\bt_\bh_\be _\bC_\bW _\bs_\be_\bc_\bt_\bi_\bo_\bn _\bo_\bf _\bt_\bh_\be _\bb_\ba_\bn_\bd_\bs _\bb_\bu_\bt _\ba_\bc_\bc_\be_\bp_\bt _\ba_\bl_\bl
- _\bo_\bt_\bh_\be_\br_\bs _\ba_\bt _\bH_\bF_\b. _\bA_\bl_\bs_\bo _\ba_\bc_\bc_\be_\bp_\bt _\ba_\bn_\by_\bt_\bh_\bi_\bn_\bg _\bi_\bn _\bV_\bH_\bF _\ba_\bn_\bd _\ba_\bb_\bo_\bv_\be _\bs_\bp_\bo_\bt_\bt_\be_\bd _\bi_\bn _\bo_\br _\bb_\by
- _\bo_\bp_\be_\br_\ba_\bt_\bo_\br_\bs _\bi_\bn _\bt_\bh_\be _\bz_\bo_\bn_\be_\bs _\b1_\b4_\b, _\b1_\b5 _\ba_\bn_\bd _\b1_\b6. Each filter slot actually has a
- 'reject' slot and an 'accept' slot. The reject slot is executed BEFORE
- the accept slot.
-
-
- 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.
-
-
-
- 8\b8.\b. O\bOt\bth\bhe\ber\br f\bfi\bil\blt\bte\ber\brs\bs
-
- 8\b8.\b.1\b1.\b. F\bFi\bil\blt\bte\ber\bri\bin\bng\bg M\bMa\bai\bil\bl
-
- 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 = (
- );
-
-
-
-
-
- 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.
-
-
- 8\b8.\b.2\b2.\b. F\bFi\bil\blt\bte\ber\bri\bin\bng\bg D\bDX\bX c\bca\bal\bll\blo\bou\but\bts\bs (\b(D\bDe\bep\bpr\bri\bic\bca\bat\bte\bed\bd)\b)
-
- _\bF_\br_\bo_\bm _\bv_\be_\br_\bs_\bi_\bo_\bn _\b1_\b._\b4_\b7_\b, _\bt_\bh_\bi_\bs _\bm_\be_\bt_\bh_\bo_\bd _\bi_\bs _\br_\be_\bp_\bl_\ba_\bc_\be_\bd _\bb_\by _\bt_\bh_\be _\bc_\bo_\bm_\bm_\ba_\bn_\bd _\bs_\be_\bt_\b/_\bb_\ba_\bd_\bd_\bx
-
-
- 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 ....
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- # 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
- );
-
-
-
-
-
- Again, this is simply a list of names we do not want to see in the
- spotted field of a DX callout.
-
-
-
- 8\b8.\b.3\b3.\b. F\bFi\bil\blt\bte\ber\bri\bin\bng\bg w\bwo\bor\brd\bds\bs f\bfr\bro\bom\bm t\bte\bex\bxt\bt f\bfi\bie\bel\bld\bds\bs i\bin\bn A\bAn\bnn\bno\bou\bun\bnc\bce\be,\b, T\bTa\bal\blk\bk a\ban\bnd\bd D\bDX\bX s\bsp\bpo\bot\bts\bs
-
- Create a file in /spider/data called _\bb_\ba_\bd_\bw_\bo_\br_\bd_\bs. The format is quite
- simple. Lines beginning with # are ignored so comments can be added.
- An example file is below ...
-
-
-
- # Below is a list of words we do not wish to see on the cluster
- grunge grunged grunging
- splodge splodger splodging
- grince
- fluffle
-
-
-
-
- Multiple words can be used on the same line as shown. Obviously these
- are just examples :-)
-
-
- You can reload the file from the cluster prompt as sysop with
- load/badwords.
-
-
- 9\b9.\b. M\bMa\bai\bil\bl
-
- DXSpider deals seamlessly with standard AK1A type mail. It supports
- both personal and bulletin mail and the sysop has additional commands
- to ensure that mail gets to where it is meant. DXSpider will send
- mail almost immediately, assuming that the target is on line.
- However, only one mail message is dealt with at any one time. If a
- mail message is already being sent or recieved, then the new message
- will be queued until it has finished.
-
- The cluster mail is automatically deleted after 30 days unless the
- sysop sets the "keep" flag using the _\bm_\bs_\bg command.
-
- 9\b9.\b.1\b1.\b. P\bPe\ber\brs\bso\bon\bna\bal\bl m\bma\bai\bil\bl
-
- Personal mail is sent using the _\bs_\bp command. This is actually the
- default method of sending mail and so a simple _\bs for send will do. A
- full list of the send commands and options is in the _\bc_\bo_\bm_\bm_\ba_\bn_\bd _\bs_\be_\bt
- section, so I will not duplicate them here.
-
-
- 9\b9.\b.2\b2.\b. B\bBu\bul\bll\ble\bet\bti\bin\bn m\bma\bai\bil\bl
-
- Bulletin mail is sent by using the _\bs_\bb command. This is one of the
- most common mistakes users make when sending mail. They send a
- bulletin mail with _\bs or _\bs_\bp instead of _\bs_\bb and of course the message
- never leaves the cluster. This can be rectified by the sysop by using
- the _\bm_\bs_\bg command.
-
-
- Bulletin addresses can be set using the Forward.pl file.
-
-
- 9\b9.\b.3\b3.\b. F\bFo\bor\brw\bwa\bar\brd\bd.\b.p\bpl\bl
-
- DXSpider receives all and any mail sent to it without any alterations
- needed in files. Because personal and bulletin mail are treated
- differently, there is no need for a list of accepted bulletin
- addresses. It is necessary, however, to tell the program which links
- accept which bulletins. For example, it is pointless sending
- bulletins addresses to "UK" to any links other than UK ones. The file
- that does this is called forward.pl and lives in /spider/msg. At
- default, like other spider files it is named forward.pl.issue. Rename
- it to forward.pl and edit the file to match your requirements. The
- format is below ...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- #
- # this is an example message forwarding file for the system
- #
- # The format of each line is as follows
- #
- # type to/from/at pattern action destinations
- # P/B/F T/F/A regex I/F [ call [, call ...] ]
- #
- # type: P - private, B - bulletin (msg), F - file (ak1a bull)
- # to/from/at: T - to field, F - from field, A - home bbs, O - origin
- # pattern: a perl regex on the field requested
- # action: I - ignore, F - forward
- # destinations: a reference to an array containing node callsigns
- #
- # if it is non-private and isn't in here then it won't get forwarded
- #
- # Currently only type B 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
- #
- # If the BBS list is undef or 0 and the action is 'F' (and it matches the
- # pattern) then it will always be forwarded to every node that doesn't have
- # it (I strongly recommend you don't use this unless you REALLY mean it, if
- # you allow a new link with this on EVERY bull will be forwarded immediately
- # on first connection)
- #
-
- package DXMsg;
-
- @forward = (
- );
-
-
-
-
- Simply insert a bulletin address and state in the brackets where you
- wish that mail to go. For example, you can see here that mail sent to
- "UK" will only be sent to the UK links and not to PA4AB-14.
-
-
- To force the cluster to reread the file use load/forward
-
-
-
- 9\b9.\b.4\b4.\b. T\bTh\bhe\be m\bms\bsg\bg c\bco\bom\bmm\bma\ban\bnd\bd
-
- The _\bm_\bs_\bg command is a very powerful and flexible tool for the sysop.
- It allows the sysop to alter to and from fields and make other changes
- to manage the cluster mail.
-
- Here is a full list of the various options ...
-
-
-
-
-
-
-
-
-
-
-
- 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 waiting 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
-
-
-
-
- These commands are simply typed from within the cluster as the sysop
- user.
-
-
- 9\b9.\b.5\b5.\b. M\bMe\bes\bss\bsa\bag\bge\be s\bst\bta\bat\btu\bus\bs
-
- You can check on a message from within the cluster by using the
- command _\bs_\bt_\ba_\bt_\b/_\bm_\bs_\bg. This will give you additional information on the
- message number including which nodes have received it, which node it
- was received from and when etc. Here is an example of the output of
- the command ...
-
-
-
- G0VGS de GB7MBC 28-Jan-2001 1308Z >
- stat/msg 6869
- From: GB7DJK
- Msg Time: 26-Jan-2001 1302Z
- Msgno: 6869
- Origin: GB7DJK
- Size: 8012
- Subject: AMSAT 2line KEPS 01025.AMSAT
- To: UK
- Got it Nodes: GB7BAA, GB7ADX
- Private: 0
- Read Confirm: 0
- Times read: 0
- G0VGS de GB7MBC 28-Jan-2001 1308Z >
-
-
-
-
-
- 9\b9.\b.6\b6.\b. F\bFi\bil\blt\bte\ber\bri\bin\bng\bg m\bma\bai\bil\bl
-
- This is described in the section on _\bO_\bt_\bh_\be_\br _\bf_\bi_\bl_\bt_\be_\br_\bs so I will not
- duplicate it here.
-
-
- 9\b9.\b.7\b7.\b. D\bDi\bis\bst\btr\bri\bib\bbu\but\bti\bio\bon\bn l\bli\bis\bst\bts\bs
-
- Distribution lists are simply a list of users to send certain types of
- mail to. An example of this is mail you only wish to send to other
- sysops. In /spider/msg there is a directory called _\bd_\bi_\bs_\bt_\br_\bo. You put
- any distibution lists in here. For example, here is a file called
- SYSOP.pl that caters for the UK sysops.
-
-
- qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX
- GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH
- GB7DXK GB7DXI GB7DXS)
-
-
-
-
- Any mail sent to "sysop" would only be sent to the callsigns in this
- list.
-
-
- 9\b9.\b.8\b8.\b. B\bBB\bBS\bS i\bin\bnt\bte\ber\brf\bfa\bac\bce\be
-
- Spider provides a simple BBS interface. No input is required from the
- sysop of the cluster at all. The BBS simply sets the cluster as a BBS
- and pushes any required mail to the cluster. No mail can flow from
- Spider to the BBS, the interface is one-way.
-
-
- Please be careful not to flood the cluster network with unnecessary
- mail. Make sure you only send mail to the clusters that want it by
- using the Forward.pl file very carefully.
-
-
- 1\b10\b0.\b. D\bDa\bat\bta\bab\bba\bas\bse\bes\bs
-
- Spider allows the creation of local or remote databases. It supports
- chained databases, allowing several different databases to be scanned
- with one simple command. Importing of databases is limited at present
- to the standard AK1A databases such as OBLAST and the DB0SDX QSL
- database but will expand with time.
-
-
- 1\b10\b0.\b.1\b1.\b. C\bCr\bre\bea\bat\bti\bin\bng\bg d\bda\bat\bta\bab\bba\bas\bse\bes\bs
-
- Creating a database could not be more simple. All the commands are
- sent from the cluster prompt as the _\bs_\by_\bs_\bo_\bp user.
-
- To create a database you use the command _\bd_\bb_\bc_\br_\be_\ba_\bt_\be. It can be used in
- 3 different ways like so ..
-
-
-
- dbcreate <name>
-
-
-
-
- To simply create a database locally, you just tell the command the
- name of the database. This does not create the actual database, it
- simply defines it to say that it exists.
-
-
-
- dbcreate <name> chain <name> [<name>...]
-
-
-
-
- This creates a chained database entry. The first database will be
- scanned, then the second, the third etc...
-
-
-
- dbcreate <name> remote <name>