Last modified: 10 December 2000 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.