1 The DXSpider Installation Manual v1.47
2 Iain Philipps, G0RDI (g0rdi@77hz.com) and Ian Maude, G0VGS,
3 (ianmaude@btinternet.com)
4 Version 1.47, April 2001 revision 1.0
6 A reference for SysOps of the DXSpider DXCluster program.
7 ______________________________________________________________________
16 1.3 Installing the software
17 1.4 Setting callsigns etc
18 1.5 Starting up for the first time
19 1.6 The Client program
21 2. Linux quick installation guide
25 3.1 Allowing ax25 connects from users
26 3.2 Allowing telnet connects from users
27 3.3 Setting up telnet connects (from 1.47 onwards)
28 3.4 Setting up for AGW Engine (1.47 onwards)
29 3.5 Setting up node connects
30 3.6 Connection scripts
31 3.7 Starting the connection
33 3.9 Autostarting the cluster
35 4. Microsoft Windows Installation
41 4.5 Additional packages
44 5. Installing the software
46 5.1 The AGW packet engine
47 5.2 Setting up the initial user files
49 5.4 Connecting to other clusters
51 6. General Information
56 ______________________________________________________________________
62 This section describes the installation of DX Spider v1.47 on a RedHat
63 Linux Distribution. Wherever possible I will try to include
64 differences for other distributions. I do not intend to try and cover
65 the installation of Linux or the setup of the AX25 utilities. If you
66 need help on this then read Iains original installation guide that
67 comes with the Spider distribution.
70 I am assuming a general knowledge of Linux and its commands. You
71 should know how to use tar and how to edit files using your favourite
75 The crucial ingredient for all of this is Perl. Earlier versions of
76 Spider required perl 5.004, however it is now STRONGLY recommended
77 that you use at least version 5.005_03 as this is the version being
78 used in the development of Spider.
81 In addition to the standard Red Hat distribution you will require the
82 following modules from http://www.cpan.org/CPAN.html ...
86 o Data-Dumper-2.101.tar.gz
88 o TimeDate-1.10.tar.gz
90 o IO-1.20.tar.gz (for perl 5.00403 and lower)
92 o Net-Telnet-3.02.tar.gz
96 o Time-HiRes-01.20.tar.gz
99 Do get the latest versions of these packages and install them but use
100 the above list as the earliest versions usable.
105 I will assume that you have already downloaded the latest tarball of
106 the DXSpider software and are ready to install it. I am assuming
107 version 1.47 for this section but of course you would use the latest
111 Login as root and create a user to run the cluster under. UNDER NO
112 CIRCUMSTANCES USE ROOT AS THIS USER!. I am going to use the name
113 sysop. You can call it anything you wish. Depending on your security
114 requirements you may wish to use an existing user, however this is
126 Now set a password for the user ...
135 # Retype new UNIX password:
136 passwd: all authentication tokens updated successfully
142 1.3. Installing the software
144 Now to unpack the DX Spider distribution, set symbolic links and group
145 permissions. Copy the tarball to /home/sysop and do the following.
150 # tar xvfz spider-1.47.tar.gz
151 # ln -s ~sysop/spider /spider
152 # groupadd -g 251 spider (or another number)
157 If you do not have the command groupadd available to you simply add a
158 line in /etc/group by hand.
162 # vi /etc/group (or your favorite editor)
167 You also need to add some others to the group, including your own
168 callsign (this will be used as an alias) and root. The finished line
169 in /etc/group should look something like this
171 spider:x:251:sysop,g0vgs,root
174 The next step is to set the permissions on the Spider directory tree
179 # chown -R sysop.spider spider
180 # find . -type d -exec chmod 2775 {} \;
181 # find . -type f -exec chmod 775 {} \;
187 This last step allows various users of the group spider to have write
188 access to all the directories. This is not really needed just yet but
189 will be useful when web interfaces start to appear.
192 Finally, you need to fix the permissions on the ax25_call and
193 netrom_call programs. Check where they are with the locate command
194 and alter the permissions with the chmod command like this ..
199 # chown root ax25_call netrom_call
200 # chmod 4775 ax25_call netrom_call
206 1.4. Setting callsigns etc
208 Now login to your machine as the user you created earlier. In my case
209 that user is called sysop. Once logged in, issue the following
217 $ cp perl/DXVars.pm.issue local/DXVars.pm
219 $ vi DXVars.pm (or your favourite editor)
225 Using the distributed DXVars.pm as a a template, set your cluster
226 callsign, sysop callsign and other user info to suit your own
227 environment. Note that this a perl file which will be parsed and
228 executed as part of the cluster. If you get it wrong then perl will
229 complain when you start the cluster process. It is important only to
230 alter the text of any section. Some of the lines look a little odd.
231 Take this line for example ....
233 $myemail = "ianmaude\@btinternet.com";
236 There appears to be an extra slash in there. However this has to be
237 there for the file to work so leave it in.
240 PLEASE USE CAPITAL LETTERS FOR CALLSIGNS
243 DON'T alter any file in /spider/perl, they are overwritten with every
244 release. Any files or commands you place in /spider/local or
245 /spider/local_cmd will automagically be used in preference to the ones
246 in /spider/perl EVEN while the cluster is running!
249 Save the new file and change directory to ../perl ....
259 Now type the following command which creates the basic user file with
271 1.5. Starting up for the first time
273 We can now bring spider up for the first time and see if all is well
274 or not! It should look something like this ...
279 DXSpider DX Cluster Version 1.47
280 Copyright (c) 1998 Dirk Koopman G1TLH
282 loading band data ...
283 loading user file system ...
284 starting listener ...
285 reading existing message headers
287 orft we jolly well go ...
293 If all is well then login on another term or console as sysop and cd
294 to /spider/src. Now issue the following command ...
304 This should log you into the cluster as the sysop under the alias
305 callsign we set earlier. In this case the callsign is G0VGS. The
306 cluster callsign is set in the DXVars.pm file in /spider/local. In
307 this case we will assume that this was set as GB7MBC. You should
308 therefore see this when you login ....
312 G0VGS de GB7MBC 19-Nov-1999 2150Z >
317 If you do, congratulations! If not, look over the instructions again,
318 you have probably missed something out. You can shut spider down
319 again with the command ....
329 and both the cluster and the client should return to Linux prompts.
331 1.6. The Client program
333 In earlier versions of Spider, all the processes were Perl scripts.
334 This was fine but with a lot of users your computer memory would soon
335 be used up. To combat this a new client was written in "C". This
336 client only works for incoming connects at the moment. Before you can
337 use it though it has to be "made". CD to /spider/src and type make.
338 You should see the output on your screen and hopefully now have a
339 small C program called client. Leave it in this directory.
343 2. Linux quick installation guide
345 This section is designed for experienced Spider sysops who want to
346 install Spider from scratch. It is simply a check list of things that
347 need to be done without any explanations. The name in brackets at the
348 end of each line is the user that should be doing that process.
353 o Get the additional CPAN modules and install them (root)
355 o Create the "sysop" user and set a password (root)
357 o Put the Spider tarball in sysop and untar it (root)
359 o ln -s sysop/spider /spider (root)
361 o groupadd -g 251 spider (root)
363 o Add any more users you need to the group entry in /etc/group (root)
365 o Set the permissions on the spider tree (root)
367 o Fix permissions on ax25_call and netrom_call (root)
369 o Login as the sysop user
371 o cd to /spider (sysop)
373 o mkdir local (sysop)
375 o mkdir local_cmd (sysop)
377 o cp perl/DXVars.pm.issue local/DXVars.pm (sysop)
379 o cd to /spider/local and edit DXVars to set your details (sysop)
383 o ./create_sysop.pl (sysop)
385 o ./cluster.pl (sysop)
387 Spider should now be running and you should be able to login using the
393 o Enter the correct line in ax25d.conf (root)
395 o Enter the correct line in /etc/services (root)
397 o Enter the correct line in /etc/inetd.conf (root)
399 o killall -HUP inetd (root)
401 Spider should now be able to accept logins via telnet, netrom and
407 o Start the cluster (sysop)
409 o set/node and type for links (sysop)
411 o Write any connect scripts (sysop)
413 o Edit /spider/crontab as required (sysop)
415 o Edit any other files as necessary (sysop)
417 o Set filters, hops and forwarding files (sysop)
421 o Enter the correct line in /etc/inittab (root)
426 3.1. Allowing ax25 connects from users
428 As stated previously, the aim of this document is not to tell you how
429 to configure Linux or the ax25 utilities. However, you do need to add
430 a line in your ax25d.conf to allow connections to DXSpider for your
431 users. For each interface that you wish to allow connections on, use
432 the following format ...
436 default * * * * * * - sysop /spider/src/client client %u ax25
441 or, if you wish your users to be able to use SSID's on their callsigns
446 default * * * * * * - sysop /spider/src/client client %s ax25
451 For most purposes this is not desirable. The only time you probably
452 will need this is when you need to allow other cluster nodes that are
453 using SSID's in. In this case it would probably be better to use the
454 first example and then add a specific line for that node like this:
458 GB7DJK-2 * * * * * * - sysop /spider/src/client client gb7djk-2 ax25
459 default * * * * * * - sysop /spider/src/client client %u ax25
463 3.2. Allowing telnet connects from users
466 From version 1.47 there is a new (more efficient) way of doing this
467 (see next section) but, if you prefer, the method of doing it
468 described here will continue to work just fine.
471 Allowing telnet connections is quite simple. Firstly you need to add
472 a line in /etc/services to allow connections to a port number, like
477 spdlogin 8000/tcp # spider anonymous login port
482 Then add a line in /etc/inetd.conf like this ....
486 spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
492 Once this is done, you need to restart inetd like this ....
503 Now login as sysop and cd spider/src. You can test that spider is
504 accepting telnet logins by issuing the following command ....
508 ./client login telnet
513 You should get a login prompt and on issuing a callsign, you will be
514 given access to the cluster. Note, you will not get a password login.
515 There seems no good reason for a password prompt to be given so it is
519 Assuming all is well, then try a telnet from your linux console ....
523 telnet localhost 8000
529 You should now get the login prompt and be able to login as before.
532 3.3. Setting up telnet connects (from 1.47 onwards)
534 From version 1.47 you can choose to allow the perl cluster.pl program
535 to allow connections directly (i.e. not via the /spider/src/client
536 interface program). If you are using Windows then this is the only
537 method available of allowing incoming telnet connections.
540 To do this you need first to remove any line that you may previously
541 have set up in /etc/inetd.conf. Remember to:-
551 to make the change happen...
554 Having done that, you need to copy the file /spider/perl/Listeners.pm
555 to /spider/local and then edit it. You will need to uncomment the line
556 containing "0.0.0.0" and select the correct port to listen on. So that
569 As standard, the listener will listen on all interfaces
570 simultaneously. If you require more control than this, you can
571 specify each interface individually:-
576 ["gb7baa.dxcluster.net", 8000],
577 ["44.131.16.2", 6300],
584 This will only be successful if the IP addresses on each interface are
585 static. If you are using some kind of dynamic IP addressing then the
586 'default' method is the only one that will work.
589 Restart the cluster.pl program to enable the listener.
592 One important difference with the internal listener is that no echoing
593 is done by the cluster program. Users will need to set 'local-echo' on
594 in their telnet clients if it isn't set automatically (as per the
595 standards). Needless to say this will probably only apply to Windows
599 3.4. Setting up for AGW Engine (1.47 onwards)
601 AGW Engine is a Windows based ax25 stack. You can connect to an AGW
602 engine from Linux as well as Windows based machines.
605 In order to enable access to an AGW Engine you need to copy
606 /spider/perl/AGWConnect.pm to /spider/local and edit it. Specifically
612 o set $login and $passwd to the values set up in your AGW
613 installation. If you haven't set any there, then you should not
616 o You can connect to a remote AGW engine (ie on some other machine)
617 by changing $addr and $port appropriately.
619 o Restart the cluster.pl program
624 3.5. Setting up node connects
626 In order to allow cluster node connections, spider needs to know that
627 the connecting callsign is a cluster node. This is the case whether
628 the connect is incoming or outgoing. In spider this is a simple task
629 and can be done in runtime.
632 Later versions of Spider can distinguish different software and treat
633 them differently. For example, the WCY beacon cannot be handles by
634 AK1A type nodes as AK1A does not know what to do with PC73. There are
635 4 different types of node at present and although they may not have
636 any major differences at the moment, it allows for compatibility. The
650 For now, we will assume that the cluster we are going to connect to is
654 Start up the cluster as you did before and login as the sysop with
655 client. The cluster node I am wanting to make a connection to is
656 GB7BAA but you would obviously use whatever callsign you required. At
667 The case does not matter as long as you have a version of DXSpider
668 later than 1.33. Earlier versions required the callsign to be in
672 That is now set, it is as simple as that. To prove it, login on yet
673 another console as sysop, cd to spider/src and issue the command ...
677 ./client gb7baa (using the callsign you set as a node)
683 You should get an initialisation string from DXSpider like this ...
693 If the callsign you just set up as a cluster node is for an incoming
694 connect, this is all that needs to be done. If the connection is to
695 be outgoing then a connection script needs to be written.
698 Sometimes you make a mistake... Honest, it does happen. If you want
699 to make a node back to being a normal user, regardless of what type it
710 3.6. Connection scripts
712 Because DXSpider operates under Linux, connections can be made using
713 just about any protocol; AX25, NETRom, tcp/ip, ROSE etc are all
714 possible examples. Connect scripts live in the /spider/connect
715 directory and are simple ascii files. Writing a script for
716 connections is therefore relatively simple.
719 The connect scripts consist of lines which start with the following
720 keywords or symbols:-
724 # All lines starting with a # are ignored, as are completely blank
728 timeout followed by a number is the number of seconds to wait
729 for a command to complete. If there is no timeout specified in
730 the script then the default is 60 seconds.
734 abort is a regular expression containing one or more strings to
735 look for to abort a connection. This is a perl regular
736 expression and is executed ignoring case.
740 connect followed by ax25, agw (for Windows users) or telnet and
741 some type dependent information. In the case of a telnet
742 connection, there can be up to two parameters. The first is the
743 ip address or hostname of the computer you wish to connect to
744 and the second is the port number you want to use (this can be
745 left out if it is a normal telnet session). In the case of an
746 ax25 session then this would normally be a call to ax25_call or
747 netrom_call as in the example above. It is your responsibility
748 to get your node and other ax25 parameters to work before going
752 ' line in a chat type script. The words/phrases normally come in
753 pairs, either can be empty. Each line reads input from the
754 connection until it sees the string (or perl regular expression)
755 contained in the left hand string. If the left hand string is
756 empty then it doesn't read or wait for anything. The comparison
757 is done ignoring case. When the left hand string has found what
758 it is looking for (if it is) then the right hand string is sent
759 to the connection. This process is repeated for every line of
764 client starts the connection, put the arguments you would want
765 here if you were starting the client program manually. You only
766 need this if the script has a different name to the callsign you
767 are trying to connect to (i.e. you have a script called other
768 which actually connects to GB7DJK-1 [instead of a script called
772 There are many possible ways to configure the script but here are
773 three examples, one for a NETRom/AX25 connect, one for AGW engines and
779 abort (Busy|Sorry|Fail)
780 # don't forget to chmod 4775 netrom_call!
781 connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh
782 # you can leave this out if you call the script 'gb7dxm'
794 abort (Busy|Sorry|Fail)
795 # this does exactly the same as the previous example
796 # the '1' is the AGW port number to connect thru for g1tlh
798 # you can leave this out if you call the script 'gb7dxm'
809 connect telnet dirkl.tobit.co.uk
810 # tell GB7DJK-1 that it is connected to GB7DJK
811 # you can leave this out if you call this script 'gb7djk'
818 Both these examples assume that everything is set up properly at the
819 other end. You will find other examples in the /spider/examples
823 3.7. Starting the connection
825 You start the connection, from within a sysop enabled cluster login,
826 by typing in the word connect followed by a script name like this ....
830 G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
831 connection to GB7DJK-1 started
832 G0VGS de GB7MBC 13-Dec-1998 2043Z >
837 This will start a connection using the script called gb7djk-1. You
838 can follow the connection by watching the term or console from where
839 you started cluster.pl. From version 1.47 onwards, you will need to
840 set/debug connect first. You should see something like this ...
859 <- D G1TLH connect gb7djk-1
860 -> D G1TLH connection to GB7DJK-1 started
861 -> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
863 CONNECT sort: telnet command: dirkl.tobit.co.uk
864 CHAT "login" -> "gb7djk"
866 Red Hat Linux release 5.1 (Manhattan)
867 Kernel 2.0.35 on an i586
871 CHAT "word" -> "gb7djk"
873 received "Password: "
875 Connected to GB7DJK-1, starting normal protocol
878 GB7DJK-1 channel func state 0 -> init
880 <- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
881 <- D GB7DJK-1 PC38^GB7DJK-1^~
882 <- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime
890 With later versions of Spider there is a set/login command for users.
891 This tells them when a user or node logs in or out. If you do not add
892 a line to your scripts after the final line (or before the client line
893 which should always be last if needed) then the login/logout
894 information will be sent to users before the login actually completes.
895 This means if a node is unreachable, it will continue sending logins
896 and logouts to users even though it is not actually connecting. To
897 avoid this use the following line ...
906 In a script, this might look like ...
911 abort (Busy|Sorry|Fail)
912 connect telnet mary 3000
920 Cluster links in particular suffer greatly from the presence of telnet
921 echo. This is caused by the telnet negotiation itself and can create
922 at worst severe loops. At best it creates unnecessary bandwidth and
923 large logfiles! There are things that can be done to limit this
924 problem but will not always work dependent on the route taken to
928 Telnet echo itself should only be a problem if the connection is being
929 made to the telnet port (23). This port uses special rules that
930 include echo negotiation. If the connection is to a different port,
931 such as 7300, this negotiation does not happen and therefore no echo
935 Sometimes it is not possible to make a direct connection to another
936 node and this can cause problems. There is a way of trying to
937 suppress the telnet echo but this will not always work, unfortunately
938 it is difficult to be more specific. Here is an example of what I
944 abort (Busy|Sorry|Fail)
945 connect telnet mary.lancs.ac.uk
950 So, the first connection is made by Spider. This is fine as Spider
951 uses the Net_Telnet script from within perl. This actually uses TCP
952 rather than TELNET so no negotiation will be done on the first
953 connection. Once connected to mary.lancs.ac.uk, the command is sent
954 to suppress echo. Now a telnet is made to a cluster node that is
955 accepting connections on port 23. The problem with this link is that
956 the negotiation is made by the remote machine, therefore you have no
957 control over it. The chances are that this link will create echo and
958 there will be no way you can stop it.
962 3.9. Autostarting the cluster
964 Ok, you should now have DXSpider running nicely and allowing connects
965 by cluster nodes or users. However, it has to be shutdown and
966 restarted manually. It would be much easier to have it start
970 This is not only a way to start the cluster automatically, it also
971 works as a watchdog, checking the sanity of DXSpider and respawning it
972 should it crash for any reason. Before doing the following, shutdown
973 the cluster as you did earlier.
976 Login as root and bring up the /etc/inittab file in your favourite
977 editor. Add the following lines to the file near the end ...
981 ##Start DXSpider on bootup and respawn it should it crash
982 DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
988 This line works fine for RedHat distributions. It is also fine for
989 SuSE up to 7.0. From Suse 7.1 you need to add runlevels 2 and 5 like
991 DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
997 The line required for Slackware distributions is slightly different.
998 My thanks to Aurelio, PA3EZL for this information.
1002 DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
1008 This will automatically start DXSpider on tty7 (ALT-F7) on bootup and
1009 restart it should it crash for any reason.
1012 As root type the command telinit q. DXSpider should start up
1013 immediately. You will see the output on tty7 and if you login as
1014 sysop you should find everything running nicely.
1017 4. Microsoft Windows Installation
1023 What you'll be left with once you've followed these instructions is
1024 (hopefully) a working DX Spider v1.47 system that is capable of
1025 accepting or originating "internet" connections, plus inbound AX.25
1026 and TCP/IP radio connections. If the absence of outbound radio
1027 connections is a serious limitation for you, it would be better for
1028 you to wait a couple more weeks until this support has been added.
1030 On the other hand, you may have an enquiring mind, or better yet, may
1031 be looking for a useful way of connecting your current (perhaps) AK1A
1032 cluster "to the internet" via some networking mechanism (BPQEther,
1033 etc) or other. I won't be producing instructions for the latter case,
1034 because I don't have an AK1A to play with. But someone might ...
1036 Whatever, this document is intended to get you started with DX Spider
1037 in a Microsoft Windows (TM) environment. It's not intended to teach
1038 you anything other than how to perform a minimum configuration of a DX
1039 Spider installation and have it able to connect across "the internet"
1040 to other DX Clusters, while accepting inbound TELNET and radio
1044 4.2. The requirements
1046 The very first things you're going to need are (in order of
1050 o A cup of good, strong tea
1052 o A supported Windows platform with an internet connection so you can
1053 download the necessary software bits and bobs directly to it. There
1054 are other ways, but this is preferable.
1057 o Another cup of good, strong tea
1059 o If all goes according to plan, about an hour to spare
1061 o Plenty of good, strong tea
1066 The platform I used to generate these instructions was a "vanilla"
1067 Microsoft Windows Me 4.90.3000 system, with a 700MHz AMD Athlon
1068 processor and 96 Mb memory. I've also personally verified that it runs
1069 on my laptop (Pentium 266MHz, 32 Mb memory, Windows 98 SE v4.10.2222
1070 A) and a computer that I assembled from a random pile of junk (AMD
1071 K6-2 333MHz, 64 Mb memory, Windows 98 v4.10.1998). As a result, I have
1072 reason to believe that what I'm about to describe will perform equally
1073 on any 32-bit MS Windows environment with 32 Mb of memory.
1075 Because of the changes that have recently been made to the core
1076 "cluster.pl" module and the introduction of a very lightweight
1077 "winclient.pl", I have a sneaking suspicion that this will now run on
1078 any platform that has reasonably complete support for Perl. Is there
1079 someone out there with both an enquiring mind and (say) a Macintosh,
1082 Please bear in mind, though, that my instructions relate solely to how
1083 to get this going under a Microsoft Windows environment, and I have
1084 zero intention of trying to make them say otherwise.
1089 Install your chosen Perl environment. Unless you have a very good
1090 reason for not doing so, I strongly suggest that you use ActivePerl
1091 v5.6. For my testing & development, I used build 623. You can get
1093 http://www.activestate.com/Products/ActivePerl/Download.html
1095 You will need to choose either the MSI or the AS package. My
1096 recommendation is that you choose the MSI package and deal with the
1097 consequences if your system isn't equipped with support for the latest
1098 MS Installer; you'll be better off in the long run. The build 623
1099 download is 7,460 KB, so now is a really good time to have some tea if
1100 you're on a slow dial-up connection.
1102 During installation, please ensure that you do choose the options to
1103 "Add Perl to the PATH environment variable" and "Create Perl file
1104 extension association"; it will make your life so much easier. Once
1105 the installation is finished, be sure to reboot your PC. You probably
1106 won't be told anywhere else that this needs to be done now, but it
1109 Once you've rebooted, open a "DOS box" (Start > Run > command might do
1110 it, if you can't find it elsewhere) and from wherever it lands, type
1111 PERL -v <ENTER> (it's better if that's a lower-case be rewarded with
1112 some interesting information about your Perl installation. If you're
1113 not, you must go back to the beginning and discover what went wrong
1114 and fix it. It's pointless to proceed unless this simple check is
1115 passed. Assuming it did work, you may now move on.
1118 4.5. Additional packages
1120 Some extensions ("packages") need to be added to the base Perl
1121 distribution, and we'll do this next. If you're using the Perl I
1122 recommended, and don't know any better for yourself, then just blindly
1123 following these instructions will work just fine. If that didn't
1124 describe you, then you're on your own.
1126 Visit the following URL:
1128 http://www.activestate.com/PPMPackages/zips/6xx-builds-only/
1130 and download the following files:-
1143 Make yourself a convenient directory to unpack all of these zip files
1144 into (I put mine in "D:\ppm>") and do the following (the bits you type
1145 in are blue ). Note that where these files land will be directly
1146 related to where you chose to install your ActivePerl (mine, as you
1147 can probably guess from what follows, went into "D:\Perl"):-
1151 D:\ppm>ppm install Data-Dumper.ppd
1152 Installing package 'Data-Dumper.ppd'
1153 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.bs
1154 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.dll
1155 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.exp
1156 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.lib
1157 Installing D:\Perl\html\site\lib\auto\Data\Dumper\Dumper.html
1158 Installing D:\Perl\site\lib\Data\Dumper\Dumper.pm
1159 Writing D:\Perl\site\lib\auto\Data\Dumper\Dumper.packlist
1165 I'm not going to bother you with exhaustive details of the rest of
1166 them, but suffice it to say you need to:
1170 ppm install DB_File.ppd
1171 ppm install Net-Telnet.ppd
1172 ppm install TimeDate.ppd
1173 ppm install Time-HiRes.ppd
1178 If all that seemed to work OK, time to move along. Before anyone who
1179 is familiar with PPM tells me that we didn't need to download and keep
1180 those files locally, I knew that. I also knew that PPM is sometimes
1181 awkward to configure via firewalls, and that sometimes the
1182 repositories don't always work the way we'd hope. I do it that way
1183 because it suits me.
1191 Get the current version of the DX Spider distribution. This needs to
1192 be v1.47 or later. You've got two ways (currently) of getting this;
1193 either get a CVS update from sourceforge (if you don't know what this
1194 is, then it isn't for you) or get my package from:-
1196 http://www.dcc.rsgb.org/WinSpider.zip
1198 or if you want the lastest CVS version (which is produced every night)
1200 http://www.dxcluster.org/download/CVSlatest.tgz
1202 If you went down the CVS route, then everything will be nicely set out
1203 on your local disk. If you got the ZIP file, unpack it to somewhere
1204 convenient. The following examples assume that you put it on drive
1205 "C:\", for convenience.
1207 NOTE: This distribution method will go away as soon as the first v1.47
1208 tarball is released. You can use WinZip to unpack that, and my life
1209 will be made easier by not needing to keep this .ZIP file updated.
1212 5. Installing the software
1214 Ensure that your CVS session or your unZIPped file have left you with
1215 a directory "C:\spider\local"; if not, go to "C:\spider\" and create
1216 one. If "C:\spider" is missing, go back and figure out why, because it
1219 Now create your own local copy of the DXVars.pm file by:-
1223 copy c:\spider\perl\DXVars.pm.issue
1224 c:\spider\local\DXVars.pm
1229 Now you'll need to edit this file using a text editor. If nothing
1230 else, you can simply
1248 to bring up an editor window containing the file. As an absolute
1249 minimum you must adjust the following items in DXVars.pm:-
1252 o $mycall - Should hold the callsign of your DX Cluster
1255 o $myname - The SysOp's first name
1257 o $myalias - the SysOp's callsign. Cannot be the same as $mycall!
1259 You really also ought to update the $mylatitude, $mylongitude, $myqth
1260 and $myemail variables. And unless you are absolutely certain you know
1261 what you're doing, you should change nothing else in this file.
1264 5.1. The AGW packet engine
1266 On the assumption that you'll be using the SV2AGW Packet Engine to
1267 interface your radios to the cluster, you should now create your own
1268 local copy of AGWConnect.pm by:-
1272 copy c:\spider\perl\AGWConnect.pm
1273 c:\spider\local\AGWConnect.pm
1282 notepad AGWConnect.pm
1287 to bring up an editor window containing the file. You must consider
1288 adjusting the following items in AGWConnect.pm:-
1291 o $enable - set to '1' to enable AGWPE interface
1293 o $login - the login ID you chose when you set up the SV2AGW
1296 o $passwd - password that matches $login
1299 5.2. Setting up the initial user files
1301 Next you need to create the initial user files, etc. A tool is
1302 supplied which will do this for you. To run the tool:-
1307 perl create_sysop.pl
1312 If all goes according to plan, you will see no output from this
1313 program, and after a brief wait, your DOS prompt will be returned.
1315 Depending on how brave you are, you might now care to try the
1326 If you did everything you were told, your DOS window will now hold a
1327 display which looks something like:-
1331 DXSpider DX Cluster Version 1.47
1332 Copyright (c) 1998-2001 Dirk Koopman G1TLH
1333 loading prefixes ...
1334 loading band data ...
1335 loading user file system ...
1336 starting listeners ...
1337 Internal port: localhost 27754
1339 reading in duplicate spot and WWV info ...
1340 reading existing message headers ...
1344 @msg = 0 before delete
1345 @msg = 0 after delete
1346 reading cron jobs ...v cron: reading /spider/cmd/crontab
1347 cron: adding 1 0 * * 0
1348 DXUser::export("$main::data/user_asc")
1349 reading database descriptors ...
1350 doing local initialisation ...
1351 orft we jolly well go ...
1357 Now, if that's what you've got, you are very nearly home and dry (in
1358 as far as these particular experiments are concerned, anyhow)
1360 To access your new cluster (from the local machine) find yourself
1361 another "DOS box" and do the following:-
1371 If you are rewarded with a display which looks something like:-
1375 Hello Iain, this is GB7SJP in Amersham, Bucks running DXSpider V1.47
1376 Cluster: 1 nodes, 1 local / 1 total users Max users 2 Uptime 0 00:00
1377 M0ADI de GB7SJP 4-Mar-2001 1511Z >
1382 You've arrived. Try some commands, and see how they feel. (In case you
1383 were wondering, "Iain", "M0ADI" and "GB7SJP" all came from the version
1384 of DXVars.pm that was on the machine when I started the winclient.pl)
1387 5.3. Incoming telnets
1389 If you want to enable inbound "TELNET" connections, you've got a
1390 little more work to do. From a handy "DOS box" that's not doing
1391 anything else, do the following:-
1395 copy \spider\perl\listeners.pm \spider\local
1397 notepad listeners.pm
1402 The following lines need attention:-
1411 On my machine, I've simply uncommented the "0.0.0.0" entry by removing
1412 the '#' from the front of the line.
1414 If you don't have a static hostname for your machine, and you intend
1415 to allow folk to connect to your machine across the internet, then I'd
1416 suggest you pay a visit to www.dyndns.org and create one for yourself.
1417 While it's free, it will take a modest an amount of effort on your
1418 part to read, understand and implement what needs to be done to set
1422 5.4. Connecting to other clusters
1424 If you want to connect this to another cluster, then you'll want to
1425 negotiate a link with someone. For experimental purposes, I'm happy to
1426 allow folk to connect to GB7DXA (spud.ath.cx), on the understanding
1427 that the system may or may not be there and may or may not be
1428 connected to anything particularly useful at any given moment. Contact
1429 me by Email if you want me to set up a connection for you.
1432 6. General Information
1434 The following relates to all versions of DXSpider and is not platform
1438 6.1. The crontab file
1440 Login as sysop and create a file in /spider/local_cmd called crontab.
1441 Edit it with your favourite editor and add a line like this (I have
1446 # check every 10 minutes to see if gb7xxx is connected and if not
1447 # start a connect job going
1449 0,10,20,30,40,50 * * * * start_connect('gb7xxx') if unless connected('gb7xxx')
1453 The callsign involved will be the callsign of the cluster node you are
1454 going to connect to. This will now check every 10 minutes to see if
1455 gb7xxx is connected, if it is then nothing will be done. If it is
1456 not, then a connect attempt will be started.
1459 There are probably lots of other things you could use this crontab
1460 file for. If you want to know more about it, look at the DXSpider
1461 website at the cron page where it is explained more fully.