Last modified: 26 January 2001 by Ian Maude, G0VGS +
Starting with version 1.13 there is simple hop control available on a per +node basis. Also it is possible to isolate a network completely so that you +get all the benefits of being on that network, but can't pass on information +from it to any other networks you may be connected to (or vice versa).
-
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: - -
-
-
-
-
Do get the latest versions of these packages and install them -but use the above list as the earliest versions usable. -
-
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. -
-
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. -
+
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 ...
-# adduser -m sysop
-
--
Now set a password for the user ... -
-
-
-# passwd sysop
-# New UNIX password:
-# Retype new UNIX password:
-passwd: all authentication tokens updated successfully
-
--
Now to unpack the DX Spider distribution, set symbolic links and group -permissions. Copy the tarball to /home/sysop and do the following. -
-
-
-# cd ~sysop
-# tar xvfz spider-1.35.tar.gz
-# ln -s ~sysop/spider /spider
-# groupadd -g 251 spider (or another number)
-
-If you do not have the command groupadd available to you simply -add a line in /etc/group by hand. -
-
-
-# vi /etc/group (or your favorite editor)
-
-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
-
-
The next step is to set the permissions on the Spider directory tree and files .... -
-
-
-# chown -R sysop.spider spider
-# find . -type d -exec chmod 2775 {} \;
-# find . -type f -exec chmod 775 {} \;
-
--
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. -
-
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 .. -
-
-
-# chown root ax25_call netrom_call
-# chmod 4775 ax25_call netrom_call
-
--
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 .... -
-
-
-$ cd /spider
-$ mkdir local
-$ mkdir local_cmd
-$ cp perl/DXVars.pm.issue local/DXVars.pm
-$ cd local
-$ vi DXVars.pm (or your favourite editor)
+# 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,
+ },
+};
-
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";
-
-
There appears to be an extra slash in there. However this has to be there -for the file to work so leave it in. -
-
PLEASE USE CAPITAL LETTERS FOR CALLSIGNS +
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.
-
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 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.
-
Save the new file and change directory to ../perl .... -
-
-
-$ cd ../perl
-
--
Now type the following command which creates the basic user file with you as -the sysop. -
-
-
-$ create_sysop.pl
-
--
We can now bring spider up for the first time and see if all is well or not! -It should look something 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 ...
-
--
If all is well then login on another term or console as sysop and -cd to /spider/perl. Now issue the following command ... -
-
-
-$ client.pl
-
--
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 .... -
-
-
-G0VGS de GB7MBC 19-Nov-1999 2150Z >
-
-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 .... +
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 +nodes 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. +
There is a lot more on filtering in the next section.