1 The DXSpider Installation Manual v1.50
2 Iain Philipps, G0RDI (g0rdi@77hz.com), Ian Maude, G0VGS,
3 (g0vgs@gb7mbc.net) and Charlie Carroll, K1XX,
5 September 2002 revision 0.4
7 A reference for SysOps of the DXSpider DXCluster program.
8 ______________________________________________________________________
71 1.3 Installing the software
72 1.4 Setting callsigns etc
73 1.5 The client program
74 1.6 Starting up for the first time
76 2. Linux quick installation guide
78 3. Setting up the AX25 Utilities
82 3.3 Installing the RPM's
89 3.10 Getting it all running
93 4.1 Allowing ax25 connects from users
94 4.2 Allowing telnet connects from users
95 4.3 Setting up telnet connects (from 1.47 onwards)
96 4.4 Setting up for AGW Engine (1.47 onwards)
97 4.5 Setting up node connects
98 4.6 Connection scripts
99 4.7 Starting the connection
101 4.9 Autostarting the cluster
103 5. Microsoft Windows Installation
109 5.5 Additional packages
112 6. Installing the software
115 6.2 The AGW packet engine
116 6.3 Setting up the initial user files
117 6.4 Connecting to other clusters
119 7. General Information
124 ______________________________________________________________________
126 1. Linux Installation
130 This section describes the installation of DX Spider v1.50 on a RedHat
131 Linux Distribution. Wherever possible I will try to include
132 differences for other distributions.
133 I am assuming a general knowledge of Linux and its commands. You
134 should know how to use tar and how to edit files using your favourite
138 The crucial ingredient for all of this is Perl. Earlier versions of
139 Spider required perl 5.004, however it is now STRONGLY recommended
140 that you use at least version 5.005_03 as this is the version being
141 used in the development of Spider.
144 In addition to the standard Red Hat distribution you will require the
145 following modules from http://www.cpan.org/modules/by-module/ , please
146 note however that with later versions of perl, some of these modules
147 may be included with the distribution. Get the modules anyway and try
148 to install as below. If they complain, they are probably already a
149 part of your perl distribution.
153 o Data-Dumper-2.10.tar.gz
155 o TimeDate-1.10.tar.gz
157 o IO-1.20.tar.gz (for perl 5.00403 and lower)
159 o Net-Telnet-3.02.tar.gz
163 o Time-HiRes-01.20.tar.gz
165 o Digest-SHA1-2.01.tar.gz
168 Copy the CPAN modules listed above to a convenient place on your
169 computer. One good place would be /usr/local/packages, and the
170 instructions which follow will assume that that's where you have put
174 Log in as 'root', and make sure you're at '/root' before you continue.
175 Here are exactly the commands you must issue next: -
199 # tar xvfz /usr/local/packages/Data-Dumper-2.10.tar.gz
200 # cd Data-Dumper-2.10
206 # tar xvfz /usr/local/packages/TimeDate-1.10.tar.gz
213 # tar xvfz /usr/local/packages/IO-1.20.tar.gz
217 # make install UNINST=1
220 # tar xvfz /usr/local/packages/Net-Telnet-3.02.tar.gz
227 # tar xvfz /usr/local/packages/Curses-1.06.tar.gz
234 # tar xvfz /usr/local/packages/Time-HiRes-01.20.tar.gz
235 # cd Time-HiRes-01.20
241 # tar xvfz /usr/local/packages/Digest-SHA1-2.01.tar.gz
242 # cd Digest-SHA1-2.01
251 Do not fall into the trap of thinking they're all the same, just
252 because they nearly are! Pay particular attention to the instructions
259 I will assume that you have already downloaded the latest tarball of
260 the DXSpider software and are ready to install it. I am assuming
261 version 1.50 for this section but of course you would use the latest
265 Login as root and create a user to run the cluster under. UNDER NO
266 CIRCUMSTANCES USE ROOT AS THIS USER!. I am going to use the name
267 sysop. You can call it anything you wish. Depending on your security
268 requirements you may wish to use an existing user, however this is
279 For SuSE distributions, the command would be ..
289 Now set a password for the user ...
295 # Retype new UNIX password:
296 passwd: all authentication tokens updated successfully
302 1.3. Installing the software
304 Now to unpack the DX Spider distribution, set symbolic links and group
305 permissions. Copy the tarball to /home/sysop and do the following.
310 # tar xvfz spider-1.50.tar.gz
311 # ln -s ~sysop/spider /spider
312 # groupadd -g 251 spider (or another number)
318 If you do not have the command groupadd available to you simply add a
319 line in /etc/group by hand.
323 # vi /etc/group (or your favorite editor)
329 You also need to add some others to the group, including your own
330 callsign (this will be used as an alias) and root. The finished line
331 in /etc/group should look something like this
333 spider:x:251:sysop,g0vgs,root
336 The next step is to set the permissions on the Spider directory tree
341 # chown -R sysop.spider spider
342 # find . -type d -exec chmod 2775 {} \;
343 # find . -type f -exec chmod 775 {} \;
349 This last step allows various users of the group spider to have write
350 access to all the directories. This is not really needed just yet but
351 will be useful when web interfaces start to appear.
354 Finally, you need to fix the permissions on the ax25_call and
355 netrom_call programs. Check where they are with the locate command
356 and alter the permissions with the chmod command like this ..
360 # chown root ax25_call netrom_call
361 # chmod 4775 ax25_call netrom_call
367 1.4. Setting callsigns etc
369 Now login to your machine as the user you created earlier. In my case
370 that user is called sysop. Once logged in, issue the following
378 $ cp perl/DXVars.pm.issue local/DXVars.pm
380 $ vi DXVars.pm (or your favourite editor)
386 Using the distributed DXVars.pm as a a template, set your cluster
387 callsign, sysop callsign and other user info to suit your own
397 This is the call sign of your cluster. If you use an SSID then
398 include it here also.
408 This is the sysop user callsign, normally your own.
411 PLEASE USE CAPITAL LETTERS FOR CALLSIGNS
414 Note that this a perl file which will be parsed and executed as part
415 of the cluster. If you get it wrong then perl will complain when you
416 start the cluster process. It is important only to alter the text of
417 any section. Some of the lines look a little odd. Take this line for
420 $myemail = "ianmaude\@btinternet.com";
423 There appears to be an extra slash in there. However this has to be
424 there for the file to work so leave it in.
427 DON'T alter any file in /spider/perl, they are overwritten with every
428 release. Any files or commands you place in /spider/local or
429 /spider/local_cmd will automagically be used in preference to the ones
430 in /spider/perl EVEN while the cluster is running!
433 Save the new file and change directory to ../perl ....
443 Now type the following command which creates the basic user file with
454 1.5. The client program
456 In earlier versions of Spider, all the processes were Perl scripts.
457 This was fine but with a lot of users your computer memory would soon
458 be used up. To combat this a new client was written in "C". This
459 client only works for incoming connects at the moment. Before you can
460 use it though it has to be "made". CD to /spider/src and type make.
461 You should see the output on your screen and hopefully now have a
462 small C program called client. Leave it in this directory.
463 1.6. Starting up for the first time
465 We can now bring spider up for the first time and see if all is well
466 or not! It should look something like this ...
471 DXSpider DX Cluster Version 1.50
472 Copyright (c) 1998 Dirk Koopman G1TLH
474 loading band data ...
475 loading user file system ...
476 starting listener ...
477 reading existing message headers
479 orft we jolly well go ...
485 If all is well then login on another term or console as sysop and cd
486 to /spider/src. Now issue the following command ...
496 This should log you into the cluster as the sysop under the alias
497 callsign we set earlier. In this case the callsign is G0VGS. The
498 cluster callsign is set in the DXVars.pm file in /spider/local. In
499 this case we will assume that this was set as GB7MBC. You should
500 therefore see this when you login ....
504 G0VGS de GB7MBC 19-Nov-1999 2150Z >
510 If you do, congratulations! If not, look over the instructions again,
511 you have probably missed something out. You can shut spider down
512 again with the command ....
522 and both the cluster and the client should return to Linux prompts.
529 2. Linux quick installation guide
531 This section is designed for experienced Spider sysops who want to
532 install Spider from scratch. It is simply a check list of things that
533 need to be done without any explanations. The name in brackets at the
534 end of each line is the user that should be doing that process.
539 o Get the additional CPAN modules and install them (root)
541 o Create the "sysop" user and set a password (root)
543 o Put the Spider tarball in sysop and untar it (root)
545 o ln -s sysop/spider /spider (root)
547 o groupadd -g 251 spider (root)
549 o Add any more users you need to the group entry in /etc/group (root)
551 o Set the permissions on the spider tree (root)
553 o Fix permissions on ax25_call and netrom_call (root)
555 o Login as the sysop user
557 o cd to /spider (sysop)
559 o mkdir local (sysop)
561 o mkdir local_cmd (sysop)
563 o cp perl/DXVars.pm.issue local/DXVars.pm (sysop)
565 o cd to /spider/local and edit DXVars to set your details (sysop)
569 o ./create_sysop.pl (sysop)
571 o ./cluster.pl (sysop)
574 Spider should now be running and you should be able to login using the
580 o Enter the correct line in ax25d.conf (root)
582 o Enter the correct line in /etc/services (root)
584 o Enter the correct line in /etc/inetd.conf (root)
586 o killall -HUP inetd (root)
589 Spider should now be able to accept logins via telnet, netrom and
595 o Start the cluster (sysop)
597 o set/node and type for links (sysop)
599 o Write any connect scripts (sysop)
601 o Edit /spider/crontab as required (sysop)
603 o Edit any other files as necessary (sysop)
605 o Set filters, hops and forwarding files (sysop)
609 o Enter the correct line in /etc/inittab (root)
612 3. Setting up the AX25 Utilities
614 The aim of this section is not to fully cover the installation and
615 configuration of all the possible ax25 modules. I will attempt to
616 cover a simple installation and configure 2 serial ports as if they
617 had TNC's on them. I will also show what additional configuration the
618 DXSpider program requires.
621 Please bear in mind that I am basing this section on a RedHat 7.1
622 distribution, if you are using SuSe or any other distibution then your
623 mileage may vary. I will be happy to make any changes and additions
624 if you email me any errors or distribution specific requirements.
627 You would probably benefit from reading the AX25-HOWTO which is much
628 more comprehensive and an interesting configuration program is also
629 available called ax25-config which may help you to configure things.
632 The following files are extracts from the working files at GB7MBC and
633 are in daily use. However, there are many ways that you can configure
634 the ax25 utils, this is just the one I use, it does not mean it is
635 necessarily the best or for that matter, the right way!
640 There are 2 things you need to do initially. You need to get the 3
641 files required for the ax25 installation and you need to make some
642 changes to the kernel configuration.
645 The first thing is to get the versions of the ax25 utils that match
646 your kernel. You may also wish to get a node package of some kind.
647 There are 2 main node packages in use of which I shall keep to the
648 original by Tomi Manninen, OH2BNS as this is included in the ax25 rpms
649 as standard. The other is AWZNode by IZ5AWZ.
652 NB: The AX25 stuff in 2.4 kernels appears to have been broken until
653 2.4.18. I strongly suggest you get at least this kernel.
656 For 2.4 kernels you need these files...
661 o libax25-0.0.7-7.i386.rpm
663 o ax25-tools-0.0.6-13.i386.rpm
665 o ax25-apps-0.0.4-9.i386.rpm
670 First you need to add Amateur Radio Support to your kernel. This is a
671 main menu item and should be easily found. Within this header you
672 will find lots of options. For our purposes you need to enable
673 Amateur Radio AX.25 Level 2 Protocol, NET/ROM and the Serial Port KISS
674 Driver. For the purposes of this document I will work under the
675 assumption that you include them in the kernel fully, ie not as
676 modules. If you need to look at compiling your kernel for ax25 more
677 fully, I would refer to the excellent AX25-HOWTO
680 I should say at this stage that NET/ROM is not mandatory. If you do
681 not use it simply ignore any instruction concerning it.
684 Now recompile your kernel in the normal way and reboot your system.
687 3.3. Installing the RPM's
689 Now install the RPM's you downloaded, libax25 first, then ax25-tools,
694 rpm -ivh libax25-0.0.7-7.i386.rpm
695 rpm -ivh ax25-tool-0.0.6-13.i386.rpm
696 rpm -ivh ax25-apps-0.0.4-9.i386.rpm
704 You will find the configuration files in /etc/ax25. These consist of
719 These are the main files. You will find other files but they do not
720 have any use unless you are wanting to use that particular protocol,
721 Rose or axip for example.
724 NOTE:- before we start it is important to realise that every interface
725 requires a different SSID. You should be able to follow this in the
729 This file sets up the ax25 ports you want to use. An example is below
730 for a standard TNC2 ...
734 #portname callsign baudrate paclen window description
735 2m gb7mbc-2 19200 256 2 2m port on 144.900MHz
736 4m gb7mbc-4 19200 256 2 4m port on 70.325MHz
742 Note that the portnames have to be unique.
745 The file headings are as follows ...
748 portname - The name you will refer to the port by
749 callsign - The ax25 callsign you want to assign to the port
750 baudrate - The speed you communicate between TNC and computer
751 paclen - The maximum packet length for ax25 connections
752 window - The ax25 window parameter. This is like 'maxframe'
753 description - A textual description of the port
760 This file sets up the netrom ports you want to use. An example is
761 below and includes a port for both cluster and node. You will see why
762 we need 2 ports later ...
766 #portname callsign alias paclen description
767 netrom gb7mbc-8 BARE 236 Node Netrom Port
768 netrom2 gb7mbc-9 MBCDX 236 Cluster Netrom Port
774 Note that the portnames have to be unique.
777 The file headings are as follows ...
780 portname - The name you will refer to the port by
781 callsign - This is the callsign that NET/ROM traffic from this
783 alias - The NET/ROM alias this port will be assigned
784 paclen - The maximum size of NET/ROM frames transmitted
785 description - A textual description of the port
795 This file sets up the netrom broadcast qualities. An example is below
800 #axport min_obs def_qual worst_qual verbose
807 The file headings are as follows ...
810 axport - The port name in axports that you wish to broadcast
812 min_obs - The minimum obsolescence value for the port
813 def_qual - The default quality for the port
814 worst_qual - The worst quality for the port. Any routes under
815 this quality will be ignored
816 verbose - This flag determines whether you will only broadcast
817 your own node (0) or all known nodes (1)
824 This file controls any incoming ax25 and NET/ROM connections and
825 steers them to the relevant program. There are lots of configuration
826 options you can set here, however they are well covered in the
827 AX25-HOWTO. For our purposes I will show a typical set of parameters.
828 An example is below ...
860 parameters 2 1 6 900 * 15 0
862 default * * * * * * - sysop /spider/src/client client %u ax25
865 parameters 2 1 6 900 * 15 0
867 default * * * * * * 0 root /usr/sbin/node node
870 parameters 2 1 6 900 * 15 0
872 default * * * * * * - sysop /spider/src/client client %u ax25
875 parameters 2 1 6 900 * 15 0
877 default * * * * * * 0 root /usr/sbin/node node
880 parameters 1 10 * * * 3 *
882 default * * * * * * - sysop /spider/src/client client %u ax25
885 parameters 1 10 * * * 3 *
887 default * * * * * * 0 root /usr/sbin/node node
893 There are a few things to take note of here. Firstly, all ax25
894 sections are wrapped in [ ] and all NET/ROM sections are wrapped in <
895 >. Secondly you should be able to see that anyone who forgets to set
896 their callsign in a TNC and tries to connect with the standard NOCALL
897 set into their TNC will not connect, the 'L' means 'lockout'. Lastly
898 and importantly, notice the order of the sections. They are all done
902 You should be able to see that the normal line for access to the
903 cluster is like this ..
907 default * * * * * * - sysop /spider/src/client client %u ax25
913 however, if you wish your users to be able to use SSID's on their
918 default * * * * * * - sysop /spider/src/client client %s ax25
925 For most purposes this is not desirable. The only time you probably
926 will need this is when you need to allow other cluster nodes that are
927 using SSID's in. In this case it would probably be better to use the
928 first example and then add a specific line for that node like this:
932 GB7DJK-2 * * * * * * - sysop /spider/src/client client gb7djk-2 ax25
933 default * * * * * * - sysop /spider/src/client client %u ax25
941 For those of you that wish to run the node, you need to set up the
942 node.conf file. There are a couple of additional files, node.perms is
943 very similar to the way ftp permissions are set up in NOS systems and
944 node.motd is the message anyone logging into the node will get. The
945 node.conf file sets all the parameters of the node as you would
946 expect. An example is below ...
991 # /etc/ax25/node.conf - LinuxNode configuration file
995 # Idle timeout (seconds).
999 # Timeout when gatewaying (seconds).
1003 # Visible hostname. Will be shown at telnet login.
1005 HostName gb7mbc.ampr.org
1013 #LocalNet 44.139.8.48/32
1015 # Command aliases. See node.conf(5) for the meaning of the uppercase
1016 # letters in the name of the alias.
1018 ##Alias CAllbook 'telnet %{2:44.17.0.53} 1235 %1 s'
1019 #Alias CONVers 'telnet %{2:oh2ti} 3600 "/n %u %{1:139}\n/w *"'
1020 #Alias CLuster 'c hkiclh'
1021 Alias CONV "telnet lurpac 3600"
1022 Alias BBS "c 70cm gb7crv"
1023 Alias DXC "telnet localhost 9000"
1024 Alias MUD "telnet homer 4000"
1025 ##Alias TEMP "finger temp@mary.g6phf"
1026 ##Alias TNOS "c ip1 gb7mbc-5"
1027 ##Alias TUtor "telnet gb7mbc 3599"
1033 # External commands. See node.conf(5) for the meaning of the uppercase
1034 # letters in the name of the extcmd.
1036 # Flags: 1 Run command through pipe
1037 # 2 Reconnected flag
1039 #ExtCmd TPM 3 nobody /usr/bin/finger finger tpm
1040 #ExtCmd ECho 1 nobody /bin/echo echo \%U \%u \%S \%s \%P \%p \%R \%r \%T \%t \%\% \%0 \%{1:foobar} \%{2} \%3 \%4 \%5
1044 NodeId "\nBARE:GB7MBC-1"
1045 #NodeId \033[01;31m***\033[0m
1047 # Netrom port name. This port is used for outgoing netrom connects.
1055 # The escape character (CTRL-T)
1059 # Resolve ip numbers to addresses?
1066 #NodePrompt "%s@%h \%i> "
1067 NodePrompt "\nBARE:GB7MBC-1 \%i > "
1068 #NodePrompt "\a\033[36m%U\033[0m de \033[01;32m#LNODE\033[0m:\033[01;33mOH2BNS-10\033[0m> "
1074 This should be fairly obvious I hope.
1077 3.10. Getting it all running
1079 Ok, now we have all the relevant files configured, the next step is to
1083 The first thing to do is attach the TNC's. Your TNC's should be in
1084 KISS mode and connected to the serial ports involved.
1087 You now use the 'kissattach' command to connect the TNC's to the
1088 system like this ...
1092 kissattach /dev/ttyS0 2m 44.131.96.199
1093 kissattach /dev/ttyS1 4m 44.131.96.199
1099 Assuming that 44.131.96.199 is your IP address. The devices ttyS0 and
1100 ttyS1 are com1 and com2 respectively. Now we can set some parameters
1105 kissparms -p 2m -t 150 -l 150 -s 50 -r 50
1106 kissparms -p 4m -t 150 -l 150 -s 50 -r 50
1112 The command 'man kissparms' will give you the explanation of the
1116 Now we need to attach the NET/ROM ports in the same way ...
1123 All of the above can be put in a file and called from
1124 /etc/rc.d/rc.local. Put all the above commands in a file called
1125 rc.ax25 and put a line in rc.local to call it.
1128 Now you can start the daemons that set everything in motion ...
1139 All should now be running. All that remains is to get the node
1140 working for telnet connections. If nothing else, this will allow you
1141 to connect to the node yourself to check on connection status etc.
1142 There are 2 files that need to be edited.
1145 First edit /etc/services and add
1149 node 3000/tcp #OH2BNS's Node Software
1155 Assuming you want it to run on port 3000
1158 Now cd /etc/xinetd.d and edit a new file called node. It should look
1164 # unencrypted username/password pairs for authentication.
1167 socket_type = stream
1170 server = /usr/sbin/node
1171 log_on_failure += USERID
1179 You now need to restart the xinetd daemon. First find out what the
1184 ps auxw |grep xinetd
1189 You will get a reply something like this ...
1193 root 592 0.0 0.1 2256 620 ? S Feb07 0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
1199 The PID or Process ID is 592 in this case so now we can issue the
1210 All should now be operational and you should be able to log into the
1211 node by using a telnet session to the relevant port, like so ...
1215 telnet localhost 3000
1221 If that works, you are just about there. you should (assuming you
1222 have radios connected to the TNC's) be able to connect out to other
1223 stations and receive incoming ax25 and netrom connections.
1228 4.1. Allowing ax25 connects from users
1230 This is dealt with in the previous section
1233 4.2. Allowing telnet connects from users
1236 >From version 1.47 there is a new (more efficient) way of doing this
1237 (see next section) but, if you prefer, the method of doing it
1238 described here will continue to work just fine.
1241 Allowing telnet connections is quite simple. Firstly you need to add
1242 a line in /etc/services to allow connections to a port number, like
1247 spdlogin 8000/tcp # spider anonymous login port
1253 Then add a line in /etc/inetd.conf like this ....
1255 spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
1261 Once this is done, you need to restart inetd like this ....
1271 Now login as sysop and cd spider/src. You can test that spider is
1272 accepting telnet logins by issuing the following command ....
1276 ./client login telnet
1282 You should get a login prompt and on issuing a callsign, you will be
1283 given access to the cluster. Note, you will not get a password login.
1284 There seems no good reason for a password prompt to be given so it is
1288 Assuming all is well, then try a telnet from your linux console ....
1292 telnet localhost 8000
1298 You should now get the login prompt and be able to login as before.
1301 4.3. Setting up telnet connects (from 1.47 onwards)
1303 >From version 1.47 you can choose to allow the perl cluster.pl program
1304 to allow connections directly (i.e. not via the /spider/src/client
1305 interface program). If you are using Windows then this is the only
1306 method available of allowing incoming telnet connections.
1309 To do this you need first to remove any line that you may previously
1310 have set up in /etc/inetd.conf. Remember to:-
1321 to make the change happen...
1324 Having done that, you need to copy the file /spider/perl/Listeners.pm
1325 to /spider/local and then edit it. You will need to uncomment the line
1326 containing "0.0.0.0" and select the correct port to listen on. So that
1327 it looks like this:-
1339 As standard, the listener will listen on all interfaces
1340 simultaneously. If you require more control than this, you can
1341 specify each interface individually:-
1346 ["gb7baa.dxcluster.net", 8000],
1347 ["44.131.16.2", 6300],
1354 This will only be successful if the IP addresses on each interface are
1355 static. If you are using some kind of dynamic IP addressing then the
1356 'default' method is the only one that will work.
1359 Restart the cluster.pl program to enable the listener.
1362 One important difference with the internal listener is that no echoing
1363 is done by the cluster program. Users will need to set 'local-echo' on
1364 in their telnet clients if it isn't set automatically (as per the
1365 standards). Needless to say this will probably only apply to Windows
1369 4.4. Setting up for AGW Engine (1.47 onwards)
1371 AGW Engine is a Windows based ax25 stack. You can connect to an AGW
1372 engine from Linux as well as Windows based machines.
1375 In order to enable access to an AGW Engine you need to copy
1376 /spider/perl/AGWConnect.pm to /spider/local and edit it. Specifically
1382 o set $login and $passwd to the values set up in your AGW
1383 installation. If you haven't set any there, then you should not
1387 o You can connect to a remote AGW engine (ie on some other machine)
1388 by changing $addr and $port appropriately.
1390 o Restart the cluster.pl program
1395 4.5. Setting up node connects
1397 In order to allow cluster node connections, spider needs to know that
1398 the connecting callsign is a cluster node. This is the case whether
1399 the connect is incoming or outgoing. In spider this is a simple task
1400 and can be done in runtime.
1403 Later versions of Spider can distinguish different software and treat
1404 them differently. For example, the WCY beacon cannot be handles by
1405 AK1A type nodes as AK1A does not know what to do with PC73. There are
1406 4 different types of node at present and although they may not have
1407 any major differences at the moment, it allows for compatibility. The
1412 set/node (AK1A type)
1421 For now, we will assume that the cluster we are going to connect to is
1425 Start up the cluster as you did before and login as the sysop with
1426 client. The cluster node I am wanting to make a connection to is
1427 GB7BAA but you would obviously use whatever callsign you required. At
1438 The case does not matter as long as you have a version of DXSpider
1439 later than 1.33. Earlier versions required the callsign to be in
1443 That is now set, it is as simple as that. To prove it, login on yet
1444 another console as sysop, cd to spider/src and issue the command ...
1448 ./client gb7baa (using the callsign you set as a node)
1453 You should get an initialisation string from DXSpider like this ...
1463 If the callsign you just set up as a cluster node is for an incoming
1464 connect, this is all that needs to be done. If the connection is to
1465 be outgoing then a connection script needs to be written.
1468 Sometimes you make a mistake... Honest, it does happen. If you want
1469 to make a node back to being a normal user, regardless of what type it
1480 4.6. Connection scripts
1482 Because DXSpider operates under Linux, connections can be made using
1483 just about any protocol; AX25, NETRom, tcp/ip, ROSE etc are all
1484 possible examples. Connect scripts live in the /spider/connect
1485 directory and are simple ascii files. Writing a script for
1486 connections is therefore relatively simple.
1489 The connect scripts consist of lines which start with the following
1490 keywords or symbols:-
1494 # All lines starting with a # are ignored, as are completely blank
1499 timeout followed by a number is the number of seconds to wait
1500 for a command to complete. If there is no timeout specified in
1501 the script then the default is 60 seconds.
1505 abort is a regular expression containing one or more strings to
1506 look for to abort a connection. This is a perl regular
1507 expression and is executed ignoring case.
1511 connect followed by ax25, agw (for Windows users) or telnet and
1512 some type dependent information. In the case of a telnet
1513 connection, there can be up to two parameters. The first is the
1514 ip address or hostname of the computer you wish to connect to
1515 and the second is the port number you want to use (this can be
1516 left out if it is a normal telnet session). In the case of an
1517 ax25 session then this would normally be a call to ax25_call or
1518 netrom_call as in the example above. It is your responsibility
1519 to get your node and other ax25 parameters to work before going
1523 ' line in a chat type script. The words/phrases normally come in
1524 pairs, either can be empty. Each line reads input from the
1525 connection until it sees the string (or perl regular expression)
1526 contained in the left hand string. If the left hand string is
1527 empty then it doesn't read or wait for anything. The comparison
1528 is done ignoring case. When the left hand string has found what
1529 it is looking for (if it is) then the right hand string is sent
1530 to the connection. This process is repeated for every line of
1535 client starts the connection, put the arguments you would want
1536 here if you were starting the client program manually. You only
1537 need this if the script has a different name to the callsign you
1538 are trying to connect to (i.e. you have a script called other
1539 which actually connects to GB7DJK-1 [instead of a script called
1543 There are many possible ways to configure the script but here are
1544 three examples, one for a NETRom/AX25 connect, one for AGW engines and
1550 abort (Busy|Sorry|Fail)
1551 # don't forget to chmod 4775 netrom_call!
1552 connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh
1553 # you can leave this out if you call the script 'gb7dxm'
1564 abort (Busy|Sorry|Fail)
1565 # this does exactly the same as the previous example
1566 # the '1' is the AGW port number to connect thru for g1tlh
1568 # you can leave this out if you call the script 'gb7dxm'
1579 connect telnet dirkl.tobit.co.uk
1580 # tell GB7DJK-1 that it is connected to GB7DJK
1581 # you can leave this out if you call this script 'gb7djk'
1582 client gb7djk telnet
1585 Both these examples assume that everything is set up properly at the
1586 other end. You will find other examples in the /spider/examples
1590 4.7. Starting the connection
1592 You start the connection, from within a sysop enabled cluster login,
1593 by typing in the word connect followed by a script name like this ....
1597 G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
1598 connection to GB7DJK-1 started
1599 G0VGS de GB7MBC 13-Dec-1998 2043Z >
1605 This will start a connection using the script called gb7djk-1. You
1606 can follow the connection by watching the term or console from where
1607 you started cluster.pl. From version 1.47 onwards, you will need to
1608 set/debug connect first. You should see something like this ...
1612 <- D G1TLH connect gb7djk-1
1613 -> D G1TLH connection to GB7DJK-1 started
1614 -> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
1616 CONNECT sort: telnet command: dirkl.tobit.co.uk
1617 CHAT "login" -> "gb7djk"
1619 Red Hat Linux release 5.1 (Manhattan)
1620 Kernel 2.0.35 on an i586
1624 CHAT "word" -> "gb7djk"
1626 received "Password: "
1628 Connected to GB7DJK-1, starting normal protocol
1629 <- O GB7DJK-1 telnet
1631 GB7DJK-1 channel func state 0 -> init
1633 <- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
1634 <- D GB7DJK-1 PC38^GB7DJK-1^~
1635 <- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime
1643 With later versions of Spider there is a set/login command for users.
1644 This tells them when a user or node logs in or out. If you do not add
1645 a line to your scripts after the final line (or before the client line
1646 which should always be last if needed) then the login/logout
1647 information will be sent to users before the login actually completes.
1648 This means if a node is unreachable, it will continue sending logins
1649 and logouts to users even though it is not actually connecting. To
1650 avoid this use the following line ...
1651 In a script, this might look like ...
1656 abort (Busy|Sorry|Fail)
1657 connect telnet mary 3000
1665 Cluster links in particular suffer greatly from the presence of telnet
1666 echo. This is caused by the telnet negotiation itself and can create
1667 at worst severe loops. At best it creates unnecessary bandwidth and
1668 large logfiles! There are things that can be done to limit this
1669 problem but will not always work dependent on the route taken to
1673 Telnet echo itself should only be a problem if the connection is being
1674 made to the telnet port (23). This port uses special rules that
1675 include echo negotiation. If the connection is to a different port,
1676 such as 7300, this negotiation does not happen and therefore no echo
1680 Sometimes it is not possible to make a direct connection to another
1681 node and this can cause problems. There is a way of trying to
1682 suppress the telnet echo but this will not always work, unfortunately
1683 it is difficult to be more specific. Here is an example of what I
1689 abort (Busy|Sorry|Fail)
1690 connect telnet mary.lancs.ac.uk
1696 So, the first connection is made by Spider. This is fine as Spider
1697 uses the Net_Telnet script from within perl. This actually uses TCP
1698 rather than TELNET so no negotiation will be done on the first
1699 connection. Once connected to mary.lancs.ac.uk, the command is sent
1700 to suppress echo. Now a telnet is made to a cluster node that is
1701 accepting connections on port 23. The problem with this link is that
1702 the negotiation is made by the remote machine, therefore you have no
1703 control over it. The chances are that this link will create echo and
1704 there will be no way you can stop it.
1708 4.9. Autostarting the cluster
1710 Ok, you should now have DXSpider running nicely and allowing connects
1711 by cluster nodes or users. However, it has to be shutdown and
1712 restarted manually. It would be much easier to have it start
1717 This is not only a way to start the cluster automatically, it also
1718 works as a watchdog, checking the sanity of DXSpider and respawning it
1719 should it crash for any reason. Before doing the following, shutdown
1720 the cluster as you did earlier.
1723 Login as root and bring up the /etc/inittab file in your favourite
1724 editor. Add the following lines to the file near the end ...
1728 ##Start DXSpider on bootup and respawn it should it crash
1729 DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
1735 This line works fine for RedHat distributions. It is also fine for
1736 SuSE up to 7.0. From SuSE 7.1 you need to add runlevels 2 and 5 like
1741 DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
1747 The line required for Slackware distributions is slightly different.
1748 My thanks to Aurelio, PA3EZL for this information.
1752 DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
1758 This will automatically start DXSpider on tty7 (ALT-F7) on bootup and
1759 restart it should it crash for any reason.
1762 NB: It should be noted that /dev/tty7 is only an example. Some SuSE
1763 systems will only accept upto tty6. It really does not matter which
1767 As root type the command telinit q. DXSpider should start up
1768 immediately. You will see the output on tty7 and if you login as
1769 sysop you should find everything running nicely.
1772 5. Microsoft Windows Installation
1778 What you'll be left with once you've followed these instructions is
1779 (hopefully) a working DX Spider v1.50 system that is capable of
1780 accepting or originating "internet" connections, plus inbound and
1781 outbound AX.25 and TCP/IP radio connections.
1783 On the other hand, you may have an enquiring mind, or better yet, may
1784 be looking for a useful way of connecting your current (perhaps) AK1A
1785 cluster "to the internet" via some networking mechanism (BPQEther,
1786 etc) or other. I won't be producing instructions for the latter case,
1787 because I don't have an AK1A to play with. But someone might ...
1789 Whatever, this document is intended to get you started with DX Spider
1790 in a Microsoft Windows (TM) environment. It's not intended to teach
1791 you anything other than how to perform a minimum configuration of a DX
1792 Spider installation and have it able to connect across "the internet"
1793 to other DX Clusters, while accepting inbound TELNET and radio
1797 5.2. The requirements
1799 The very first things you're going to need are (in order of
1803 o A cup of good, strong tea
1805 o A supported Windows platform with an internet connection so you can
1806 download the necessary software bits and bobs directly to it. There
1807 are other ways, but this is preferable.
1809 o Another cup of good, strong tea
1811 o If all goes according to plan, about an hour to spare
1813 o Plenty of good, strong tea
1818 The platform I used to generate these instructions was a "vanilla"
1819 Microsoft Windows Me 4.90.3000 system, with a 700MHz AMD Athlon
1820 processor and 96 Mb memory. I've also personally verified that it runs
1821 on my laptop (Pentium 266MHz, 32 Mb memory, Windows 98 SE v4.10.2222
1822 A) and a computer that I assembled from a random pile of junk (AMD
1823 K6-2 333MHz, 64 Mb memory, Windows 98 v4.10.1998). As a result, I have
1824 reason to believe that what I'm about to describe will perform equally
1825 on any 32-bit MS Windows environment with 32 Mb of memory.
1827 Because of the changes that have recently been made to the core
1828 "cluster.pl" module and the introduction of a very lightweight
1829 "winclient.pl", I have a sneaking suspicion that this will now run on
1830 any platform that has reasonably complete support for Perl. Is there
1831 someone out there with both an enquiring mind and (say) a Macintosh,
1834 Please bear in mind, though, that my instructions relate solely to how
1835 to get this going under a Microsoft Windows environment, and I have
1836 zero intention of trying to make them say otherwise.
1841 Install your chosen Perl environment. Unless you have a very good
1842 reason for not doing so, I strongly suggest that you use ActivePerl
1843 v5.6. For my testing & development, I used build 623. (A recent
1844 installation used the newer ActivePerl v5.6.1, build 633 without any
1845 noticable difficulty.) You can get this from:
1846 http://www.activestate.com/Products/ActivePerl/Download.html
1849 The link takes you to an initial page of System Requirements and
1850 Software Prerequisites. If you do not have it already installed, you
1851 can download and install the Windows Installer 2.0 for a Win98
1852 installation. Be forewarned, you will have to reboot your PC at the
1853 completion of the installer's installation.
1855 If you already have the installer on your PC, simply click on the Next
1856 arrow at the bottom of the page. Two clicks will finally get you to
1857 the actual download page. The MSI version of Build 633 is now 8.6MB
1858 in size, so make that a big cup of tea or coffee if you're on a slow
1861 During installation, please ensure that you do choose the options to
1862 "Add Perl to the PATH environment variable" and "Create Perl file
1863 extension association"; it will make your life so much easier. Once
1864 the installation is finished, be sure to reboot your PC. You probably
1865 won't be told anywhere else that this needs to be done now, but it
1868 Once you've rebooted, open a "DOS box" (Start > Run > command might do
1869 it, if you can't find it elsewhere) and from wherever it lands, type
1870 PERL -v <ENTER> (it's better if that's a lower-case be rewarded with
1871 some interesting information about your Perl installation. If you're
1872 not, you must go back to the beginning and discover what went wrong
1873 and fix it. It's pointless to proceed unless this simple check is
1874 passed. Assuming it did work, you may now move on.
1877 5.5. Additional packages
1879 Some extensions ("packages") need to be added to the base Perl
1880 distribution, and we'll do this next. If you're using the Perl I
1881 recommended, and don't know any better for yourself, then just blindly
1882 following these instructions will work just fine. If that didn't
1883 describe you, then you're on your own.
1885 Visit the following URL:
1887 http://www.activestate.com/PPMPackages/zips/6xx-builds-only/
1889 and download the following files:-
1902 If this is a new installation, now would also be a good time to
1903 install a copy of WinZip on your PC. Make yourself a convenient
1904 directory to unpack all of these zip files into (I put mine in
1905 "D:\ppm>" but "C:\ppm" works just as well.) and do the following (the
1906 bits you type in are blue ). You can upzip all of the files into the
1907 same directory. When prompted, simply overwrite the Readme file from
1908 each zip package. Note that where these files land will be directly
1909 related to where you chose to install your ActivePerl (mine, as you
1910 can probably guess from what follows, went into "D:\Perl"):-
1915 D:\ppm>ppm install Data-Dumper.ppd
1916 Installing package 'Data-Dumper.ppd'
1917 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.bs
1918 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.dll
1919 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.exp
1920 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.lib
1921 Installing D:\Perl\html\site\lib\auto\Data\Dumper\Dumper.html
1922 Installing D:\Perl\site\lib\Data\Dumper\Dumper.pm
1923 Writing D:\Perl\site\lib\auto\Data\Dumper\Dumper.packlist
1929 I'm not going to bother you with exhaustive details of the rest of
1930 them, but suffice it to say you need to:
1934 ppm install DB_File.ppd
1935 ppm install Net-Telnet.ppd
1936 ppm install TimeDate.ppd
1937 ppm install Time-HiRes.ppd
1942 If all that seemed to work OK, time to move along. Before anyone who
1943 is familiar with PPM tells me that we didn't need to download and keep
1944 those files locally, I knew that. I also knew that PPM is sometimes
1945 awkward to configure via firewalls, and that sometimes the
1946 repositories don't always work the way we'd hope. I do it that way
1947 because it suits me.
1952 Get the current version of the DX Spider distribution. This needs to
1953 be v1.50 or later. You've got two ways (currently) of getting this;
1954 either get a CVS update from sourceforge (if you don't know what this
1955 is, then it isn't for you) or get the latest "official" release from:
1957 http://www.dxcluster.org/download/index.html
1959 or if you want the lastest snapshot of CVS version (which is produced
1962 http://www.dxcluster.org/download/CVSlatest.tgz
1964 This is generally the best one to go for as it is completely up to
1965 date. However, there is always the very slight chance that it might
1966 unstable. Generally, there will be a note on the website if this is
1970 The only difference between "CVSlatest.tgz" and the latest "official"
1971 release version is that it is more up to date. Do not confuse the
1972 "CVSlatest.tgz" file with "Downloading from Sourceforge with CVS" -
1973 they are two quite different things. "Downloading from Sourceforge
1974 with CVS" is explained in a section within the Admin manual.
1977 If you go down the CVS route (ie installing WinCVS as explained in the
1978 Admin manual and downloaded from sourceforge), then everything will be
1979 nicely installed on your local disk. If you got the CVSlatest.tgz
1980 file, unzip (winzip) it to "C:\". This is an important point since
1981 paths are included within the .tgz file. Make sure you unzip to the
1982 root directory of whichever drive you use... "C:\" or "D:\" or ..,
1983 not "C:\spider." If you double click on CVSlatest.tgz, WinZip should
1984 open with a dialogue box that says the Archive contains a single file
1985 (CVSlatest.tar) and asks whether WinZip should decompress it to a
1986 temporary fold and then open it. Say "Yes" and then you will get the
1987 typical Classical WinZip listing of files ready for extraction.
1988 Remember, extract them to your desired root directory ("C:\" or "D:\"
1989 or ...). The following examples assume that you put it on drive
1990 "C:\", for convenience.
1993 6. Installing the software
1995 At this point you will need to create 2 additional directories under
1996 "C:\Spider." Make directories "C:\spider\local" and
1997 "C:\spider\local_cmd". If "C:\spider" is missing, go back and figure
1998 out why, because it shouldn't be.
2000 Now create your own local copy of the DXVars.pm file by:-
2004 copy c:\spider\perl\DXVars.pm.issue
2005 c:\spider\local\DXVars.pm
2010 Now you'll need to edit this file using a text editor like Notepad. If
2011 nothing else, you can simply
2029 to bring up an editor window containing the file. As an absolute
2030 minimum you must adjust the following items in DXVars.pm:-
2033 o $mycall - Should hold the callsign of your DX Cluster
2035 o $myname - The SysOp's first name
2037 o $myalias - the SysOp's callsign. Cannot be the same as $mycall!
2039 o $myqth - The station's geographical location (QTH).
2041 o $mylatitude - The station latitude in degrees and decimal fractions
2043 o $mylongitude - The station longitude in degrees and decimal
2047 o $mylocator - The Maidenhead (or QRA) locator of the station
2049 You really also ought to update the $myqth and $myemail variables. And
2050 unless you are absolutely certain you know what you're doing, you
2051 should change nothing else in this file. Note that if you use an "@"
2052 or a "$" character in one of the above strings (typically in $myemail)
2053 you must write them as "\@" or "\$".
2056 6.1. Incoming telnets
2058 If you want to enable inbound "TELNET" connections (or you are running
2059 Windows 98, NT, 2000 or XP), you've got a little more work to do. From
2060 a handy "DOS box" that's not doing anything else, do the following:-
2064 copy \spider\perl\Listeners.pm \spider\local
2066 notepad listeners.pm
2071 The following line need attention:-
2075 # ["0.0.0.0", 7300],
2080 On my machine, I've simply uncommented the "0.0.0.0" entry by removing
2081 the '#' from the front of the line.
2083 You MUST carry out this step if you are running on a Windows 98, NT,
2084 2000 or XP based system
2086 If you don't have a static hostname for your machine, and you intend
2087 to allow folk to connect to your machine across the internet, then I'd
2088 suggest you pay a visit to www.dyndns.org and create one for yourself.
2089 While it's free, it will take a modest amount of effort on your part
2090 to read, understand and implement what needs to be done to set this
2094 If your machine is connected to the internet and you don't want to
2095 allow your machine to be visible to the outside world you should
2096 change the "0.0.0.0" to "127.0.0.1" [which is "localhost"]. This will
2097 then only allow connections from inside your machine. As was said
2098 earlier: if you aren't running Win9x (or you want to use DXTelnet or
2099 somesuch), then you need to have the machine listening at least to
2100 "127.0.0.1" ("0.0.0.0" means all IP addresses).
2103 6.2. The AGW packet engine
2105 On the assumption that you'll be using the SV2AGW Packet Engine to
2106 interface your radios to the cluster, it would be a good idea to
2107 download the Packet Engine software! You can get this software from:
2109 http://www.raag.org/sv2agw/agwpe.zip
2111 Depending upon your TNCs, you may also need to get:
2113 http://www.raag.org/sv2agw/drivers.zip
2115 A couple of the tools:
2117 http://www.raag.org/sv2agw/agwterm.zip
2119 http://www.raag.org/sv2agw/agwmonitor.zip
2121 will also help with troubleshooting of the RF links themselves.
2123 Install and configure AGWPE. You should now create your own local
2124 copy of AGWConnect.pm by:-
2128 copy c:\spider\perl\AGWConnect.pm
2129 c:\spider\local\AGWConnect.pm
2138 notepad AGWConnect.pm
2143 to bring up an editor window containing the file. You must consider
2144 adjusting the following items in AGWConnect.pm:-
2147 o $enable - set to '1' to enable AGWPE interface
2149 o $login - the login ID you chose when you set up the SV2AGW
2152 o $passwd - password that matches $login
2154 The login ID and passwd only need to be set if you are accessing AGW
2155 separately via its web interface. This interface is normally not
2156 needed for use with DXSpider.
2159 6.3. Setting up the initial user files
2161 Next you need to create the initial user files, etc. A tool is
2162 supplied which will do this for you. To run the tool:-
2167 perl create_sysop.pl
2172 If all goes according to plan, you will see no output from this
2173 program, and after a brief wait, your DOS prompt will be returned.
2175 Depending on how brave you are, you might now care to try the
2184 If you did everything you were told, your DOS window will now hold a
2185 display which looks something like:-
2189 DXSpider DX Cluster Version 1.50
2190 Copyright (c) 1998-2002 Dirk Koopman G1TLH
2191 loading prefixes ...
2192 loading band data ...
2193 loading user file system ...
2194 starting listeners ...
2195 Internal port: localhost 27754
2197 reading in duplicate spot and WWV info ...
2198 reading existing message headers ...
2202 @msg = 0 before delete
2203 @msg = 0 after delete
2204 reading cron jobs ...v cron: reading /spider/cmd/crontab
2205 cron: adding 1 0 * * 0
2206 DXUser::export("$main::data/user_asc")
2207 reading database descriptors ...
2208 doing local initialisation ...
2209 orft we jolly well go ...
2215 Now, if that's what you've got, you are very nearly home and dry (in
2216 as far as these particular experiments are concerned, anyhow)
2218 If you are running Windows 9x you can access your new cluster (from
2219 the local machine) by finding yourself another "DOS box" and doing the
2230 If you are running Windows NT, 2000 or XP then winclient.pl does not
2231 work. We don't know why other than this seems to be some kind of
2232 incomaptibility in perl. You can achieve the same thing by telnetting
2233 to the port you defined in Listeners.pm (7300 as default), thus:-
2238 telnet localhost 7300
2243 On getting the login: prompt, enter your sysop callsign (the one you
2244 put in DXVars.pm as $myalias).
2245 I would recommend strongly that you obtain a better telnet client than
2246 that which comes with windows (I use PuTTY).
2249 Anyway, if you are rewarded with a display which looks something
2254 Hello Iain, this is GB7SJP in Amersham, Bucks running DXSpider V1.50
2255 Cluster: 1 nodes, 1 local / 1 total users Max users 2 Uptime 0 00:00
2256 M0ADI de GB7SJP 4-Mar-2001 1511Z >
2261 You've arrived. Try some commands, and see how they feel. (In case you
2262 were wondering, "Iain", "M0ADI" and "GB7SJP" all came from the version
2263 of DXVars.pm that was on the machine when I started the winclient.pl)
2266 The interface is very basic. It is a simple command line. There are
2267 better looking interfaces. Most of the "standard" logging and DX
2268 Cluster access programs that are capable of connecting via a TCP or
2269 telnet connection will work as a "Sysop Console" client. You connect
2270 to "localhost" on the port that you defined in Listeners.pm (usually
2271 7300). I recommend packages like DXTelnet.
2274 6.4. Connecting to other clusters
2276 If you want to connect this to another cluster, then you'll want to
2277 negotiate a link with someone. For experimental purposes, I'm happy to
2278 allow folk to connect to GB7DXA (spud.ath.cx), on the understanding
2279 that the system may or may not be there and may or may not be
2280 connected to anything particularly useful at any given moment. Contact
2281 me by Email if you want me to set up a connection for you.
2284 7. General Information
2286 The following relates to all versions of DXSpider and is not platform
2290 7.1. The crontab file
2292 Login as sysop and create a file in /spider/local_cmd called crontab.
2293 Edit it with your favourite editor and add a line like this (I have
2298 # check every 10 minutes to see if gb7xxx is connected and if not
2299 # start a connect job going
2301 0,10,20,30,40,50 * * * * start_connect('gb7xxx') unless connected('gb7xxx')
2307 The callsign involved will be the callsign of the cluster node you are
2308 going to connect to. This will now check every 10 minutes to see if
2309 gb7xxx is connected, if it is then nothing will be done. If it is
2310 not, then a connect attempt will be started.
2311 There are probably lots of other things you could use this crontab
2312 file for. If you want to know more about it, look at the DXSpider
2313 website at the cron page where it is explained more fully.