X-Git-Url: http://scm.dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=html%2Fadminmanual-1.html;h=78a3afcce12c625dae012178036e7a2516ed98be;hb=06cf973726ecfc228d68bc82b63feb026d897a68;hp=3e247fc2c7608847e01d16a56c15f3218ac077ee;hpb=04f192bf9da26bd6fbed506a2cbb2a10dda25d35;p=spider.git diff --git a/html/adminmanual-1.html b/html/adminmanual-1.html index 3e247fc2..78a3afcc 100644 --- a/html/adminmanual-1.html +++ b/html/adminmanual-1.html @@ -2,209 +2,468 @@
-Last modified: 1 September 2000 by Ian Maude, G0VGS -
This section describes the installation of DX Spider v1.35 on a -RedHat Linux Distribution. I do not intend to try and cover the installation of Linux or the setup of the AX25 utilities. If you need help on this then read Iains original HOWTO on the -DXSpider website. -
-
I am assuming a general knowledge of Linux and its commands. You should know how to use tar and how to edit files using your favourite editor. -
-
The crucial ingredient for all of this is -Perl 5.004.Now I know Perl 5.005 is out and this will almost certainly work with it, but -RedHat 5.1 comes with 5.004. Be Warned, earlier versions of -RedHat do not come with 5.004 as standard, you need to -upgrade
-
In addition to the standard Red Hat distribution you will require the following -CPAN modules: - +
From DXSpider version 1.48, major changes were introduced to the way +node connections are treated. This is part of an ongoing process to +remove problems with loops and to enable talk and other functions to +propagate across the whole of the worldwide cluster network. In fact, +in a Spider network, it would be useful, perhaps even necessary to +have loops. This would give real resilience to the network, meaning +that if a link dropped, the information flow would simply come in and +go out via a different route. Of course, we do not have a complete +network of Spider nodes, there are other programs out there. Some of +these do not have any protection from loops. Certainly AK1A does not +handle loops well at all. It is therefore necessary to have some form +of protection for these nodes. +
+
This is achieved by using filtering on a route basis. There is a +default setting to help to protect the network, especially useful for new +and inexperienced SysOps. The idea is simple. When Spider is started +for the first time and a connection is made to or from another node, +the default is to only send the nodes you already have that are in your +own zone. For example, in the UK the default setting would be to send +only UK nodes to any connection. This can be filtered further (down to +a single node if needed) or expanded as required. +
+
+
As mentioned in the introduction, a default setting exists. If this is +all you want to use then that is fine, you have nothing else to do. +However, if you want to make any alterations then you need to know +a bit about filters. +
+
It is possible to reset the default setting for node connections should +you wish to do so, however this can be dangerous to the network unless +you have some experience in how all this works.... be careful! It is +also possible to change settings for one connection only. You can, +therefore, have many different filters set dependent on the amount of +node links you have. +
+
I should at this stage give a little bit of background on filters. All +the filters in Spider work in basically the same way. You can either +accept or reject various options in order to create the filter rules +you wish to achieve. Some filters are user settable, others can only +be altered by the sysop. Route filtering can only be done by the sysop. +
+
As discussed previously, a default setting exists that only sends nodes +from your own zone. This can be overridden by using the default_node +filter option like this ...
+
+
+reject/route default_node <filter_option>
+
+or
+
+accept/route default_node <filter_option>
+
+
-
where filter_option is one of the following ...
+
+
+call <prefixes>
+call_dxcc <numbers>
+call_itu <numbers>
+call_zone <numbers>
+origin <prefixes>
+origin_dxcc <numbers>
+origin_itu <numbers>
+origin_zone <numbers>
+
+
-
Do get the latest versions of these packages and install them but use the above list as the earliest versions usable. +
Please be careful if you alter this setting, it will affect +ALL your links!
-
I will assume that you have already downloaded the latest tarball of the DXSpider software and are ready to install it. I am assuming version 1.35 for this section but of course you would use the latest version. +
Exactly the same rules apply for general route filtering. You would +use either an accept filter or a reject filter like this ...
-
Login as root and create a user to run the cluster under. UNDER NO CIRCUMSTANCES USE ROOT AS THIS USER!. I am going to use the name sysop. You can call it anything you wish. Depending on your security requirements you may wish to use an existing user, however this is your own choice. +
+
+reject/route <node_call> <filter_option>
+
+or
+
+accept/route <node_call> <filter_option>
+
+
+
where filter_option is one of the following ...
-# adduser -m sysop
+call <prefixes>
+call_dxcc <numbers>
+call_itu <numbers>
+call_zone <numbers>
+origin <prefixes>
+origin_dxcc <numbers>
+origin_itu <numbers>
+origin_zone <numbers>
-
Now set a password for the user ... +
Here are some examples of route filters ...
-# passwd sysop
-# New UNIX password:
-# Retype new UNIX password:
-passwd: all authentication tokens updated successfully
+rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes)
+rej/route all (equiv to [very] restricted mode)
+acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
+acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)
-
Now to unpack the DX Spider distribution, set symbolic links and group permissions. Copy the tarball to /home/sysop and do the following. +
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. +
+
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. +
+
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 ...
-# cd ~sysop
-# tar xvfz spider-1.35.tar.gz
-# ln -s ~sysop/spider /spider
-# groupadd -g 251 spider (or another number)
+
+accept/spots .....
+reject/spots .....
-If you do not have the command groupadd available to you simply add a line in /etc/group by hand. +
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 ...
-# vi /etc/group (or your favorite editor)
+clear/spots 1
+clear/spots all
-You also need to add some others to the group, including your own callsign (this will be used as an alias) and root. The finished line in /etc/group should look something like this -
spider:x:251:sysop,g0vgs,root
+
There is clear/xxxx command for each type of filter.
-
The next step is to set the permissions on the Spider directory tree and files .... +
and you can check that your filters have worked by the command ...
-# chown -R sysop.spider spider
-# find . -type d -exec chmod 2775 {} \;
-# find . -type f -exec chmod 775 {} \;
+
+show/filter
-
This last step allows various users of the group spider to have write access to all the directories. This is not really needed just yet but will be useful when web interfaces start to appear. +
For now we are going to use spots for the examples, but you can apply the same +principles to all types of filter.
-
Finally, you need to fix the permissions on the ax25_call and netrom_call programs. Check where they are with the locate command and alter the permissions with the chmod command like this .. +
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) +
+
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 ...
-# chown root ax25_call netrom_call
-# chmod 4775 ax25_call netrom_call
+accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
+then you will ONLY get VHF spots from or to CQ zones +14, 15 and 16.
-
Now login to your machine as the user you created earlier. In my case that user is called sysop. Once logged in, issue the following commands .... +
If you set a reject filter like this ... +
+
+
+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 ... +
+
+
+reject/spots on hf/cw and not info iota
+
+
+But in that case you might only be interested in iota and say:-
-$ cd /spider
-$ mkdir local
-$ mkdir local_cmd
-$ cp perl/DXVars.pm.issue local/DXVars.pm
-$ cd local
-$ vi DXVars.pm (or your favourite editor)
+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!
-
Using the distributed DXVars.pm as a a template, set your cluster callsign, sysop callsign and other user info to suit your own environment. Note that this a perl file which will be parsed and executed as part of the cluster. If you get it wrong then perl will complain when you start the cluster process. It is important only to alter the text of any section. Some of the lines look a little odd. Take this line for example .... -
$myemail = "ianmaude\@btinternet.com";
+
You can arrange your filter lines into logical units, either for your own +understanding or simply convenience. Here is an example ...
-
There appears to be an extra slash in there. However this has to be there for the file to work so leave it in. +
+
+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.
-
PLEASE USE CAPITAL LETTERS FOR CALLSIGNS +
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.
-
DON'T alter the DXVars.pm (or any other file) in /spider/perl, they are overwritten with every release. Any files or commands you place in /spider/local or /spider/local_cmd will automagically be used in preference to the ones in /spider/perl EVEN while the cluster is running! +
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 ...
-
Save the new file and change directory to ../perl .... +
+
+(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 ...
-$ cd ../perl
+reject/spots 1 on hf/ssb
+would redefine our earlier example, or
-
Now type the following command which creates the basic user file with you as the sysop. +
+
+clear/spots 1
+
+
+To remove all the filter lines in the spot filter ...
-$ create_sysop.pl
+clear/spots all
-
We can now bring spider up for the first time and see if all is well or not! It should look something like this ... +
You can filter in several different ways. The options are listed in the +various helpfiles for accept, reject and filter. +
+
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 ...
-$ cluster.pl
-DXSpider DX Cluster Version 1.35
-Copyright (c) 1998 Dirk Koopman G1TLH
-loading prefixes ...
-loading band data ...
-loading user file system ...
-starting listener ...
-reading existing message headers
-reading cron jobs
-orft we jolly well go ...
+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. +
+
Once you are happy with the results you get, you may like to experiment.
-
If all is well then login on another term or console as sysop and cd to /spider/perl. Now issue the following command ... +
The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU +can be written with a mixed filter, for example ...
-$ client.pl
+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)
--
This should log you into the cluster as the sysop under the alias callsign we set earlier. In this case the callsign is G0VGS. The cluster callsign is set in the DXVars.pm file in /spider/local. In this case we will assume that this was set as GB7MBC. You should therefore see this when you login .... +
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. +
+
In /spider/data you will find a file called hop_table.pl. This is the file +that controls your hop count settings. It has a set of default hops on the +various PC frames and also a set for each node you want to alter the hops for. +You may be happy with the default settings of course, but this powerful tool +can help to protect and improve the network. The file will look something +like this ...
-G0VGS de GB7MBC 19-Nov-1999 2150Z >
+#
+# hop table construction
+#
+
+package DXProt;
+
+# default hopcount to use
+$def_hopcount = 5;
+
+# some variable hop counts based on message type
+%hopcount =
+(
+ 11 => 10,
+ 16 => 10,
+ 17 => 10,
+ 19 => 10,
+ 21 => 10,
+);
+
+
+# the per node hop control thingy
+
+
+%nodehops =
+
+ GB7ADX => { 11 => 8,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+
+ GB7UDX => { 11 => 8,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+ GB7BAA => {
+ 11 => 5,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+};
-If you do, congratulations! If not, look over the instructions again, you have probably missed something out. You can shut spider down again with the command .... +
+
Each set of hops is contained within a pair of curly braces and contains a +series of PC frame types. PC11 for example is a DX spot. The figures here +are not exhaustive but should give you a good idea of how the file works. +
+
You can alter this file at any time, including whilst the cluster is running. +If you alter the file during runtime, the command load/hops will +bring your changes into effect. +
+
It is possible to isolate networks from each other on a "gateway" node using the +set/isolate <node_call> command. +
+
The effect of this is to partition an isolated network completely from another +node connected to your node. Your node will appear on and otherwise behave +normally on every network to which you are connected, but data from an isolated +network will not cross onto any other network or vice versa. However all the +spot, announce and WWV traffic and personal messages will still be handled +locally (because you are a real node on all connected networks), that is locally +connected users will appear on all networks and will be able to access and +receive information from all networks transparently. All routed messages will +be sent as normal, so if a user on one network knows that you are a gateway for +another network, he can still still send a talk/announce etc message via your +node and it will be routed across. +
+
The only limitation currently is that non-private messages cannot be passed down +isolated links regardless of whether they are generated locally. This will change +when the bulletin routing facility is added. +
+
If you use isolate on a node connection you will continue to receive all +information from the isolated partner, however you will not pass any information +back to the isolated node. There are times when you would like to forward only +spots across a link (maybe during a contest for example). To do this, isolate +the node in the normal way and put in a filter in the /spider/filter/spots +directory to override the isolate. This filter can be very simple and consists +of just one line ....
-shutdown
+$in = [
+ [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
+];
-
and both the cluster and the client should return to Linux prompts. -