X-Git-Url: http://dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=html%2Fadminmanual-4.html;h=40e432549ffab2f1bea4e71a12f1c9c777c51a52;hb=b1d4f4f651821a3ecefdd59ddb09ce9d190b66d6;hp=48e5702a0d5f5567ffe489adbbb9908391a59be7;hpb=b8ff94755eecda16276c449274c6a76c4f14a8d1;p=spider.git diff --git a/html/adminmanual-4.html b/html/adminmanual-4.html index 48e5702a..40e43254 100644 --- a/html/adminmanual-4.html +++ b/html/adminmanual-4.html @@ -2,7 +2,7 @@ - The DXSpider Administration Manual v1.47: Other filters + The DXSpider Administration Manual v1.48: Scripts @@ -13,118 +13,68 @@ Previous Contents
-

4. Other filters

+

4. Scripts

-

4.1 Filtering Mail -

- -

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 .... +

From 1.48 onwards it will become increasingly possible to control DXSpider's +operation with scripts of various kinds.

-

-
-
-# 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. -

-

4.2 Filtering DX callouts (Depricated) -

- -

From version 1.47, this method is replaced by the command set/baddx -

-

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 directory /spider/scripts is where it all happens and is used for several +things. Firstly it contains a file called startup that can be used to call +in any changes to the cluster from the default settings on startup. This +script is executed immediately after all initialisation of the node is done +but before any connections are possible. Examples of this include how many +spots it is possible to get with the sh/dx command, whether you want +registration/passwords to be permanently on etc. An example file is shown +below and is included in the distribution as startup.issue.

-
-# 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 
-);
+#
+# startup script example
+#
+# set maximum no of spots allowed to 100
+# set/var $Spot::maxspots = 1
+#
+# Set registration on
+# set/var $main::reqreg = 1
+#
+# Set passwords on
+# set/var $main::passwdreq = 1
+#
 

-

Again, this is simply a list of names we do not want to see in the spotted -field of a DX callout. -

-

-

4.3 Filtering words from text fields in Announce, Talk and DX spots -

- -

Create a file in /spider/data called badwords. The format is quite -simple. Lines beginning with # are ignored so comments can be added. An -example file is below ... +

As usual, any text behind a # is treated as a comment and not read. +

Secondly, it is used to store the login scripts for users and nodes. Currently +this can only be done by the sysop but it is envisaged that eventually users will +be able to set their own. An example is included in the distibution but here is +a further example.

-# Below is a list of words we do not wish to see on the cluster
-grunge grunged grunging
-splodge splodger splodging
-grince
-fluffle
+#
+# G0FYD
+#
+blank +
+sh/wwv 3
+blank +
+sh/dx 
+blank +
+t g0jhc You abt?
+blank +
 
-

Multiple words can be used on the same line as shown. Obviously these -are just examples :-) +

The lines in between commands can simply insert a blank line or a character +such as a + sign to make the output easier to read. Simply create this script +with your favourite editor and save it with the callsign of the user as the +filename. Filenames should always be in lower case. +

+

Commands can be inserted in the same way for nodes. A node may wish a series +of commands to be issued on login, such as a merge command for example.

-

You can reload the file from the cluster prompt as sysop with load/badwords. +

Thirdly, there are 2 default scripts for users and nodes who do not have a +specifically defined script. These are user_default and +node_default


Next