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). +
Ok, you should now have DXSpider running nicely and allowing connects by cluster +nodes or users. However, it has to be shutdown and restarted manually and if +connection scripts fail they have to be started again manually too, not much use +if you are not at the console! So, in this section we will automate both. +Firstly starting the cluster.
-
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 ... +
This is not only a way to start the cluster automatically, it also works as a +watchdog, checking the sanity of DXSpider and respawning it should it crash for +any reason. Before doing the following, shutdown the cluster as you did earlier. +
+
Login as root and bring up the /etc/inittab file in your favourite editor. Add +the following lines to the file near the end ...
-#
-# 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,
- },
-};
+##Start DXSpider on bootup and respawn it should it crash
+DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
+
++
This line works fine for RedHat distributions. It is also fine for SuSE up to +7.0. From Suse 7.1 you need to add runlevels 2 and 5 like this ... +
+
+
+DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
-
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. +
The line required for Slackware distributions is slightly different. My thanks to +Aurelio, PA3EZL for this information.
-
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. +
+
+DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
+
+-
It is possible to isolate networks from each other on a "gateway" node using the -set/isolate <node_call> command. +
This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart +it should it crash for any reason.
-
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. +
As root type the command telinit q. DXSpider should start up +immediately. You will see the output on tty7 and if you login as sysop +you should find everything running nicely.
-
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. +
So far so good, now to automate script connections...
-
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 .... +
Login as sysop and create a file in /spider/local_cmd called crontab. +Edit it with your favourite editor and add a line like this (I have included +a comment)
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+# check every 10 minutes to see if gb7xxx is connected and if not
+# start a connect job going
+
+0,10,20,30,40,50 * * * * start_connect('gb7xxx') if !connected('gb7xxx')
-
There is a lot more on filtering in the next section. +
The callsign involved will be the callsign of the cluster node you are +going to connect to. This will now check every 10 minutes to see if +gb7xxx is connected, if it is then nothing will be done. If it is not, +then a connect attempt will be started. +
+
There are probably lots of other things you could use this crontab file for. +If you want to know more about it, look at the +DXSpider website +at the cron page where it is explained more fully.