X-Git-Url: http://gb7djk.dxcluster.net/gitweb/gitweb.cgi?a=blobdiff_plain;f=html%2Fadminmanual-7.html;h=7d30a63e8566f030803008abd78c0155c7a45c1a;hb=09f90105aa04bc675d50b42fa59013a8291696b0;hp=5a60b9dec1e6b1ec2fc43e966ff08d292dce8085;hpb=4fa8a0251b64361c908d056393b46abece6d38be;p=spider.git diff --git a/html/adminmanual-7.html b/html/adminmanual-7.html index 5a60b9de..7d30a63e 100644 --- a/html/adminmanual-7.html +++ b/html/adminmanual-7.html @@ -2,523 +2,236 @@ - The DXSpider Installation and Administration Manual : Sysop commands + The DXSpider Installation and Administration Manual : Filtering (New Style v1.45 and later) + -Next +Next Previous Contents
-

7. Sysop commands

+

7. Filtering (New Style v1.45 and later)

-

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

-

7.1 announce sysop (5) -

- -

announce sysop <text> -

-

Send an announcement to Sysops only -

-

7.2 connect (5) +

7.1 General filter rules

-

connect <callsign> Start a connection to another DX Cluster +

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.

-

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

There are 3 basic commands involved in setting and manipulating filters. These +are accept, reject and clear. 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.

-

-

7.3 catch (9) -

- -

<node_call> All [<msgno> ...] Mark a message as sent -

-

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:- -

catch GB7DJK all -catch GB7DJK 300 301 302 303 -

and to undo what you have just done:- -

uncatch GB7DJK all -uncatch GB7DJK 300 301 302 303 -

which will arrange for them to be forward candidates again. -

-

7.4 dbcreate (9) -

- -

dbcreate <name> Create a database entry
-dbcreate <name> chain <name> [<name>..] Create a chained database entry
-dbcreate <name> remote <node> Create a remote database entry
-

-

DBCREATE allows you to define a database in the system. It doesn't actually -create anything, just defines it. -

The databases that are created are simple DB_File hash databases, they are -therefore already 'indexed'. -

You can define a local database with the first form of the command eg: -

DBCREATE oblast -

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: -

DBCREATE sdx_qsl chain sql_ad -

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

Databases can exist offsite. To define a database that lives on another -node do: -

DBCREATE buckmaster remote gb7dxc -

Remote databases cannot be chained; however, the last database in a -a chain can be a remote database eg: -

DBCREATE qsl chain gb7dxc -

To see what databases have been defined do: -

DBAVAIL (or it will have been aliased to SHOW/COMMAND) -

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

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

-  's' => [
-    ..
-    ..
-    '^sh\w*/buc', 'dbshow buckmaster', 'dbshow',
-    ..
-    ..
-   ],
+ 
+accept/spots .....
+reject/spots .....
 
-

to allow -

SH/BUCK g1tlh -

to work as they may be used to. -

See DBIMPORT for the importing of existing AK1A format data to databases. -See DBSHOW for generic database enquiry -

-

7.5 dbimport (9) -

- -

dbimport <dbname> Import AK1A data into a database -

-

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:- -

DBIMPORT oblast /tmp/OBLAST.FUL -

will import the standard OBLAST database that comes with AK1A into the -oblast database held locally. -

-

7.6 dbremove (9) -

- -

dbremove <dbname> Delete a database -

-

DBREMOVE will completely remove a database entry and also delete any data -file that is associated with it. -

There is no warning, no comeback, no safety net. -

For example: -

DBREMOVE oblast -

will remove the oblast database from the system and it will also remove -the associated datafile. -

I repeat: -

There is no warning, no comeback, no safety net. -

You have been warned. -

-

7.7 debug (9) -

- -

debug Set the cluster program into debug mode -

-

Executing this command will only have an effect if you are running the cluster -in debug mode i.e. +

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

There is also a command to clear out one or more lines in a filter. They are ...

-        perl -d cluster.pl
+clear/spots 1
+clear/spots all
 
-

It will interrupt the cluster just after the debug command has finished. -

-

7.8 directory (5) -

- -

Works just like the user command except that sysops can see ALL messages. -

-

7.9 disconnect (8) -

- -

disconnect <call> [<call> ...] Disconnect a user or node -

-

Disconnect any <call> connected locally +

There is clear/xxxx command for each type of filter.

-

7.10 export (9) -

- -

export <msgno> <filename> Export a message to a file -

-

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

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:- -

EXPORT 2345 /tmp/a -

-

7.11 forward/opername (1) -

- -

forward/opername <call> Send out information on this <call> to all clusters -

-

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

-

7.12 init (5) -

- -

init <node call> Re-initialise a link to an AK1A compatible node -

-

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

Best of luck - you will need it. -

-

7.13 kill (5) -

- -

kill <msgno> [<msgno> ...] Remove or erase a message from the system
-kill from <call> Remove all messages from a callsign
-kill to <call> Remove all messages to a callsign
-

-

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

As a sysop you can kill any message on the system. -

-

7.14 kill full (5) -kill full <msgno> [<msgno>] Delete a message from the whole cluster

- -

Delete a message (usually a 'bulletin') from the whole cluster system. -

This uses the subject field, so any messages that have exactly the same subject -will be deleted. Beware! -

-

7.15 load/aliases (9) -

- -

load/aliases Reload the command alias table -

-

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

-

7.16 load/bands (9) -

- -

load/bands Reload the band limits table -

-

Reload the /spider/data/bands.pl file if you have changed it manually whilst -the cluster is running. -

-

7.17 load/cmd_cache (9) -

- -

load/cmd_cache Reload the automatic command cache -

-

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

-

7.18 load/messages (9) -

- -

load/messages Reload the system messages file -

-

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 :- -

unknown message 'xxxx' in lang 'en' -

-

7.19 load/prefixes (9) -

- -

load/prefixes Reload the prefix table -

-

Reload the /spider/data/prefix_data.pl file if you have changed it manually whilst -the cluster is running. -

-

7.20 merge (5) -

- -

merge <node> [<no spots>/<no wwv>] Ask for the latest spots and WWV -

-

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

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

-

7.21 msg (9) -

- -

msg <cmd> <msgno> [data ...] Alter various message parameters -

-

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

and you can check that your filters have worked by the command ...

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

You can look at the status of a message by using:- -

STAT/MSG <msgno> -

This will display more information on the message than DIR does. -

-

7.22 pc (8) -

- -

pc <call> <text> Send text (eg PC Protocol) to <call> -

-

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:- -

pc gb7djk PC33^GB7TLH^GB7DJK^400^ -

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

pc G1TLH Try doing that properly!!! -

-

7.23 ping (1) -

- -

ping <node> Send a ping command to another cluster node -

-

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

Any visible cluster node can be PINGed. -

-

7.24 rcmd (1) -

- -

rcmd <node call> <cmd> Send a command to another DX cluster -

-

This command allows you to send nearly any command to another DX Cluster -node that is connected to the system. -

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

-

7.25 read (5) -

- -

read <msgno> Read a message on the system -

-

As a sysop you may read any message on the system -

-

7.26 set/debug (9) -

- -

set/debug <name>Add a debug level to the debug set -

-

You can remove this level with unset/debug <name> -

-

7.27 set/isolate (9) -

- -

set/isolate <node call> Isolate a node from the rest of the network -

-

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

You can potentially connect several nodes in this way. -

You can see which nodes are isolated with the show/isolate (1) command. -

You can remove the isolation with the command unset/isolate. -

-

7.28 set/sys_location (9) -

- -

set/sys_location <lat & long>Set your cluster latitude and longitude

-

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:- -

SET/LOCATION 52 22 N 0 57 E +

For now we are going to use spots for the examples, but you can apply the same +principles to all types of filter.

-

7.29 set/lockout (9) +

7.2 Types of filter

-

set/lockout <call>Stop a callsign connecting to the cluster +

There are two main types of filter, accept or reject. 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)

-

You can show who is locked out with the show/lockout (9) command. -

To allow the user to connect again, use the command unset/lockout -

-

7.30 set/node (9) -

- -

set/node <call> [<call> ...]Make the callsign an AK1A cluster -

-

Tell the system that the call(s) are to be treated as AK1A cluster and -fed PC Protocol rather normal user commands. -

From version 1.41 you can also set the following types of cluster +

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 accept filter ...

+

-set/spider
-set/dxnet
-set/clx
-set/arcluster
+accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
 
-

To see what your nodes are set to, use the show/nodes command. -

-

7.31 set/obscount (9) -

- -

set/obscount <count> <node call> Set the 'pump-up' obscelence counter +

+

then you will ONLY get VHF spots from or to CQ zones +14, 15 and 16.

-

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

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

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

If you set a reject filter like this ...

-

7.32 set/pinginterval (9) -

- -

set/pinginterval <time> <node call> Set the ping time to neighbouring nodes +

+
+reject/spots on hf/cw
+
+
+

Then you will get everything EXCEPT 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 ...

-

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

You can use this command to set a different interval. Please don't. -

But if you do the value you enter is treated as minutes up 60 and seconds -for numbers greater than that. -

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

+
+reject/spots on hf/cw and not info iota
+
+
+

But in that case you might only be interested in iota and say:-

-

7.33 set/privilege (9) -

- -

set/privilege <n> <call> [<call> ...] Set the privilege level on a call +

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

-

Set the privilege level on a callsign. The privilege levels that pertain -to commands are as default:- +

You can arrange your filter lines into logical units, either for your own +understanding or simply convenience. Here is an example ...

-  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)  
 
-

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

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.

-

7.34 set/password (9) -

- -

set/password <callsign> <string> Set a users password +

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.

-

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

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

-

7.35 set/sys_qra (9) -

- -

set/sys_qra <locator> Set your cluster QRA locator -

-

7.36 show program (5) -

- -

show/program Show the locations of all the included program modules +

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

-

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

+
+reject/spots 1 on hf/ssb
+
+
+

would redefine our earlier example, or

-

7.37 shutdown (5) -

- -

shutdownShutdown the cluster +

+
+clear/spots 1
+
+
+

To remove all the filter lines in the spot filter ...

-

Shutdown the cluster and disconnect all the users. If you have Spider -set to respawn in /etc/inittab it will of course restart. +

+
+clear/spots all
+
+

-

7.38 stat/db (5) +

7.3 Filter options

-

stat/db <dbname> Show the status of a database +

You can filter in several different ways. The options are listed in the +various helpfiles for accept, reject and filter.

-

Show the internal status of a database descriptor. -

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

-

7.39 stat/channel (5) +

7.4 Default filters

-

stat/channel <callsign> Show the status of a channel on the cluster +

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

-

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

Only the fields that are defined (in perl term) will be displayed. +

+
+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.40 stat/msg (5) +

7.5 Advanced filtering

-

stat/msg <msgno> Show the status of a message +

Once you are happy with the results you get, you may like to experiment.

-

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

-

7.41 stat/user (5) -

- -

stat/user <callsign> Show the full status of a user +

The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU +can be written with a mixed filter, for example ...

-

Shows the full contents of a user record including all the secret flags -and stuff. -

Only the fields that are defined (in perl term) will be displayed. +

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


-Next +Next Previous Contents