1 <!doctype linuxdoc system>
5 <!-- Title information -->
7 <title>The DXSpider Installation Manual v1.50</title>
8 <author>Iain Philipps, G0RDI (g0rdi@77hz.com),
9 Ian Maude, G0VGS, (g0vgs@gb7mbc.net) and Charlie
10 Carroll, K1XX, (k1xx@ptcnh.net)</author>
11 <date>March 2003 revision 0.7</date>
14 A reference for SysOps of the DXSpider DXCluster program.
17 <!-- Table of contents -->
20 <!-- Begin the document -->
22 <sect>Linux Installation
27 This section describes the installation of DX Spider v1.50 on a
28 <htmlurl url="http://www.redhat.com" name="RedHat"> Linux Distribution.
29 Wherever possible I will try to include differences for other distributions.
32 I am assuming a general knowledge of Linux and its commands. You should
33 know how to use <em>tar</em> and how to edit files using your favourite editor.
36 The crucial ingredient for all of this is
37 <htmlurl url="http://www.perl.org" name="Perl">. Earlier versions of
38 Spider required perl 5.004, however it is now <it>STRONGLY</it> recommended
39 that you use at least version 5.6.1 as this is the version being used
40 in the development of Spider.
43 In addition to the standard Red Hat distribution you will require the
44 following modules from <htmlurl url="http://www.cpan.org/modules/by-module/" name="http://www.cpan.org/modules/by-module/"> , please note however that with later versions of perl, some of these
45 modules may be included with the distribution. Get the modules anyway and try
46 to install as below. If they complain, they are probably already a part of your
51 <item> <htmlurl url="http://www.cpan.org/modules/by-module/Data/Data-Dumper-2.101.tar.gz" name="Data-Dumper-2.101.tar.gz"> <em> this is included in perl 5.6.1 and above </em>
52 <item> <htmlurl url="http://www.cpan.org/modules/by-module/Date/TimeDate-2.27.tar.gz" name="TimeDate-2.27.tar.gz">
53 <item> <htmlurl url="http://www.cpan.org/modules/by-module/IO/IO-1.20.tar.gz" name="IO-1.20.tar.gz"> (<em>for perl 5.00403 and lower</em>)
54 <item> <htmlurl url="http://www.cpan.org/modules/by-module/Net/Net-Telnet-3.03.tar.gz" name="Net-Telnet-3.03.tar.gz">
55 <item> <htmlurl url="http://www.cpan.org/modules/by-module/Curses/Curses-1.08a.tar.gz" name="Curses-1.08a.tar.gz">
56 <item> <htmlurl url="http://www.cpan.org/modules/by-module/Time/Time-HiRes-01.20.tar.gz" name="Time-HiRes-01.20.tar.gz"> (<em>for perl versions lower than 5.8 </em>)
57 <item> <htmlurl url="http://www.cpan.org/modules/by-module/Digest/Digest-SHA1-2.01.tar.gz" name="Digest-SHA1-2.01.tar.gz">
61 On most modern distributions most (if not all) the modules you will need are either included or
62 can be loaded automatically. Please consult your distro's instructions for loading new programs
63 and look for modules that usually start with the string "perl-". For instance:-
66 <item>Mandrake: urpmi perl-TimeDate perl-Digest-SHA1 perl-Curses perl-Net-Telnet
67 <item>Redhat/Fedora: up2date perl-TimeDate perl-Digest-SHA1 perl-Curses perl-Net-Telnet
69 <item>Debian: use apt-get
73 Some distros are now packaging perl-DB_File separately as well, so you may have to add that to the list
77 Copy the CPAN modules listed above to a convenient place on your computer. One good
78 place would be /usr/local/packages, and the instructions which follow will assume that
79 that's where you have put them.
82 Log in as 'root', and make sure you're at '/root' before you continue. Here are exactly the commands you must issue next: -
85 # tar xvfz /usr/local/packages/TimeDate-2.27.tar.gz
92 # tar xvfz /usr/local/packages/Net-Telnet-3.03.tar.gz
99 # tar xvfz /usr/local/packages/Curses-1.08a.tar.gz
106 # tar xvfz /usr/local/packages/Time-HiRes-01.20.tar.gz
107 # cd Time-HiRes-01.20
113 # tar xvfz /usr/local/packages/Digest-SHA1-2.01.tar.gz
114 # cd Digest-SHA1-2.01
122 Only if you need to do these because your perl is old:-
126 # tar xvfz /usr/local/packages/IO-1.20.tar.gz
130 # make install UNINST=1
133 # tar xvfz /usr/local/packages/Data-Dumper-2.101.tar.gz
134 # cd Data-Dumper-2.101
143 Do not fall into the trap of thinking they're all the same, just because they
144 nearly are! Pay particular attention to the instructions of <em>IO</em>, above.
150 I will assume that you have already downloaded the latest tarball of
151 the DXSpider software and are ready to install it. I am assuming version
152 1.50 for this section but of course you would use the latest version.
155 Login as root and create a user to run the cluster under. <bf><it>UNDER
156 NO CIRCUMSTANCES USE ROOT AS THIS USER!</it></bf>. I am going to use
157 the name <em>sysop</em>. You can call it anything you wish. Depending
158 on your security requirements you may wish to use an existing user,
159 however this is your own choice.
166 For SuSE distributions, the command would be ..
173 Now set a password for the user ...
178 # Retype new UNIX password:
179 passwd: all authentication tokens updated successfully
182 <sect1>Installing the software
185 Now to unpack the DX Spider distribution, set symbolic links and group
186 permissions. Copy the tarball to /home/sysop and do the following.
190 # tar xvfz spider-1.50.tar.gz
191 # ln -s ~sysop/spider /spider
192 # groupadd -g 251 spider (or another number)
196 If you do not have the command <em>groupadd</em> available to you simply
197 add a line in /etc/group by hand.
200 # vi /etc/group (or your favorite editor)
204 You also need to add some others to the group, including your own callsign
205 (this will be used as an alias) and root. The finished line in /etc/group
206 should look something like this
209 spider:x:251:sysop,g0vgs,root
213 The next step is to set the permissions on the Spider directory tree and files ....
216 # chown -R sysop.spider spider
217 # find . -type d -exec chmod 2775 {} \;
218 # find . -type f -exec chmod 775 {} \;
222 This last step allows various users of the group <em>spider</em> to have
223 write access to all the directories. This is not really needed just yet
224 but will be useful when web interfaces start to appear.
227 Finally, you need to fix the permissions on the ax25_call and netrom_call
228 programs. Check where they are with the <em>locate</em> command and alter
229 the permissions with the <em>chmod</em> command like this ..
232 # chown root ax25_call netrom_call
233 # chmod 4775 ax25_call netrom_call
236 <sect1>Setting callsigns etc
239 Now login to your machine as the user you created earlier. In my case that
240 user is called <em>sysop</em>. Once logged in, issue the following commands ....
246 $ cp perl/DXVars.pm.issue local/DXVars.pm
248 $ vi DXVars.pm (or your favourite editor)
252 Using the distributed DXVars.pm as a a template, set your cluster callsign,
253 sysop callsign and other user info to suit your own environment.
260 This is the call sign of your cluster. Here in the UK we have
261 separate callsigns for our cluster nodes. If you can't use a different callsign I suggest
262 you use an SSID of '-2' for the node callsign '$mycall'.
269 This is the sysop user callsign, normally your own.
272 <bf>PLEASE USE CAPITAL LETTERS FOR CALLSIGNS</bf>
275 Note that this a perl file which will be parsed and executed as part of the
276 cluster. If you get it wrong then perl will complain when you start the cluster
277 process. It is important only to alter the text of any section. Some of the
278 lines look a little odd. Take this line for example ....
281 $myemail = "ianmaude\@btinternet.com";
285 There appears to be an extra slash in there. However this has to be there
286 for the file to work so leave it in.
289 DON'T alter any file in /spider/perl, they are overwritten with every
290 release. Any files or commands you place in /spider/local or /spider/local_cmd
291 will automagically be used in preference to the ones in /spider/perl EVEN
292 while the cluster is running!
295 Save the new file and change directory to ../perl ....
302 Now type the following command which creates the basic user file with you as
309 <sect1>The client program
312 In earlier versions of Spider, all the processes were Perl scripts. This
313 was fine but with a lot of users your computer memory would soon be used up.
314 To combat this a new client was written in "C". This client only works for
315 <em>incoming</em> connects at the moment. Before you can use it though it
316 has to be "made". CD to /spider/src and type <em>make</em>. You
317 should see the output on your screen and hopefully now have a small C program
318 called <em>client</em>. Leave it in this directory.
321 <sect1>Starting up for the first time
324 We can now bring spider up for the first time and see if all is well or not!
325 It should look something like this ...
329 DXSpider DX Cluster Version 1.50
330 Copyright (c) 1998 Dirk Koopman G1TLH
332 loading band data ...
333 loading user file system ...
334 starting listener ...
335 reading existing message headers
337 orft we jolly well go ...
341 If all is well then login on another term or console as <em>sysop</em> and
342 cd to /spider/src. Now issue the following command ...
349 This should log you into the cluster as the sysop under the alias callsign we
350 set earlier. In this case the callsign is G0VGS. The cluster callsign is set
351 in the DXVars.pm file in /spider/local. In this case we will assume that this
352 was set as GB7MBC. You should therefore see this when you login ....
355 G0VGS de GB7MBC 19-Nov-1999 2150Z >
359 If you do, congratulations! If not, look over the instructions again, you
360 have probably missed something out. You can shut spider down again with the
368 and both the cluster and the client should return to Linux prompts.
371 <sect>Linux quick installation guide
374 This section is designed for experienced Spider sysops who want to install
375 Spider from scratch. It is simply a check list of things that need to be
376 done without any explanations. The name in brackets at the end of each line
377 is the user that should be doing that process.
381 <item>Get the additional CPAN modules and install them (root)
382 <item>Create the "sysop" user and set a password (root)
383 <item>Put the Spider tarball in ~sysop and untar it (root)
384 <item>ln -s ~sysop/spider /spider (root)
385 <item>groupadd -g 251 spider (root)
386 <item>Add any more users you need to the group entry in /etc/group (root)
387 <item>Set the permissions on the spider tree (root)
388 <item>Fix permissions on ax25_call and netrom_call (root)
389 <item>Login as the sysop user
390 <item>cd to /spider (sysop)
391 <item>mkdir local (sysop)
392 <item>mkdir local_cmd (sysop)
393 <item>cp perl/DXVars.pm.issue local/DXVars.pm (sysop)
394 <item>cd to /spider/local and edit DXVars to set your details (sysop)
395 <item>cd ../perl (sysop)
396 <item>./create_sysop.pl (sysop)
397 <item>./cluster.pl (sysop)
401 Spider should now be running and you should be able to login using the
406 <item>Enter the correct line in ax25d.conf (root)
407 <item>Enter the correct line in /etc/services (root)
408 <item>Enter the correct line in /etc/inetd.conf (root)
409 <item>killall -HUP inetd (root)
413 Spider should now be able to accept logins via telnet, netrom and ax25.
417 <item>Start the cluster (sysop)
418 <item>set/node and type for links (sysop)
419 <item>Write any connect scripts (sysop)
420 <item>Edit /spider/crontab as required (sysop)
421 <item>Edit any other files as necessary (sysop)
422 <item>Set filters, hops and forwarding files (sysop)
424 <item>Enter the correct line in /etc/inittab (root)
427 <sect>Setting up the AX25 Utilities
430 The aim of this section is not to fully cover the installation
431 and configuration of all the possible ax25 modules. I will
432 attempt to cover a simple installation and configure 2 serial
433 ports as if they had TNC's on them. I will also show what
434 additional configuration the DXSpider program requires.
437 Please bear in mind that I am basing this section on a RedHat
438 7.1 distribution, if you are using SuSe or any other distibution
439 then your mileage may vary. I will be happy to make any changes
440 and additions if you email me any errors or distribution specific
444 You would probably benefit from reading the <htmlurl url="http://www.fokus.gmd.de/linux/HOWTO/html_single/AX25-HOWTO.html#AEN151" name="AX25-HOWTO"> which is much more
445 comprehensive and an interesting configuration program is also available
446 called <htmlurl url="http://1409.org/projects/index.html" name="ax25-config"> which
447 may help you to configure things.
450 The following files are extracts from the working files at GB7MBC and
451 are in daily use. However, there are many ways that you can configure the
452 ax25 utils, this is just the one I use, it does not mean it is necessarily
453 the best or for that matter, the right way!
455 <sect1>Getting Started
458 There are 2 things you need to do initially. You need to get the
459 3 files required for the ax25 installation and you need to make
460 some changes to the kernel configuration.
463 The first thing is to get the versions of the ax25 utils that match
464 your kernel. You may also wish to get a node package of some kind.
465 There are 2 main node packages in use of which I shall keep to the
466 original by Tomi Manninen, OH2BNS as this is included in the ax25
467 rpms as standard. The other is <htmlurl url="ftp://ftp.funet.fi/pub/ham/packet/linux/awznode/" name="AWZNode"> by IZ5AWZ.
470 NB: The AX25 stuff in 2.4 kernels appears to have been broken until 2.4.18. I
471 strongly suggest you get at least this kernel.
474 For 2.4 kernels you need these files...
478 <item> <htmlurl url="ftp://ftp.rpmfind.net/linux/redhat/7.1/en/powertools/i386/RedHat/RPMS/libax25-0.0.7-7.i386.rpm" name="libax25-0.0.7-7.i386.rpm">
479 <item> <htmlurl url="ftp://ftp.rpmfind.net/linux/redhat/7.1/en/powertools/i386/RedHat/RPMS/ax25-tools-0.0.6-13.i386.rpm" name="ax25-tools-0.0.6-13.i386.rpm">
480 <item> <htmlurl url="ftp://ftp.rpmfind.net/linux/redhat/7.1/en/powertools/i386/RedHat/RPMS/ax25-apps-0.0.4-9.i386.rpm" name="ax25-apps-0.0.4-9.i386.rpm">
486 First you need to add Amateur Radio Support to your kernel. This is
487 a main menu item and should be easily found. Within this header you
488 will find lots of options. For our purposes you need to enable
489 Amateur Radio AX.25 Level 2 Protocol, NET/ROM and the Serial Port
490 KISS Driver. For the purposes of this document I will work under the
491 assumption that you include them in the kernel fully, ie not as modules.
492 If you need to look at compiling your kernel for ax25 more fully, I would
493 refer to the excellent
494 <htmlurl url="http://www.fokus.gmd.de/linux/HOWTO/html_single/AX25-HOWTO.html#AEN151" name="AX25-HOWTO">
497 I should say at this stage that NET/ROM is not mandatory. If you do not use it
498 simply ignore any instruction concerning it.
501 Now recompile your kernel in the normal way and reboot your system.
503 <sect1>Installing the RPM's
506 Now install the RPM's you downloaded, libax25 first, then ax25-tools,
510 rpm -ivh libax25-0.0.7-7.i386.rpm
511 rpm -ivh ax25-tool-0.0.6-13.i386.rpm
512 rpm -ivh ax25-apps-0.0.4-9.i386.rpm
518 You will find the configuration files in /etc/ax25. These consist of
530 These are the main files. You will find other files but they do not
531 have any use unless you are wanting to use that particular protocol,
532 Rose or axip for example.
535 NOTE:- before we start it is important to realise that every interface
536 requires a different SSID. You should be able to follow this in the
542 This file sets up the ax25 ports you want to use. An example is below
543 for a standard TNC2 ...
546 #portname callsign baudrate paclen window description
547 2m gb7mbc-2 19200 256 2 2m port on 144.900MHz
548 4m gb7mbc-4 19200 256 2 4m port on 70.325MHz
552 Note that the portnames have to be unique.
555 The file headings are as follows ...
558 portname - The name you will refer to the port by
559 callsign - The ax25 callsign you want to assign to the port
560 baudrate - The speed you communicate between TNC and computer
561 paclen - The maximum packet length for ax25 connections
562 window - The ax25 window parameter. This is like 'maxframe'
563 description - A textual description of the port
569 This file sets up the netrom ports you want to use. An example is below
570 and includes a port for both cluster and node. You will see why we need
574 #portname callsign alias paclen description
575 netrom gb7mbc-8 BARE 236 Node Netrom Port
576 netrom2 gb7mbc-9 MBCDX 236 Cluster Netrom Port
580 Note that the portnames have to be unique.
583 The file headings are as follows ...
586 portname - The name you will refer to the port by
587 callsign - This is the callsign that NET/ROM traffic from this
589 alias - The NET/ROM alias this port will be assigned
590 paclen - The maximum size of NET/ROM frames transmitted
591 description - A textual description of the port
597 This file sets up the netrom broadcast qualities. An example is below ...
600 #axport min_obs def_qual worst_qual verbose
605 The file headings are as follows ...
608 axport - The port name in axports that you wish to broadcast
610 min_obs - The minimum obsolescence value for the port
611 def_qual - The default quality for the port
612 worst_qual - The worst quality for the port. Any routes under
613 this quality will be ignored
614 verbose - This flag determines whether you will only broadcast
615 your own node (0) or all known nodes (1)
621 This file controls any incoming ax25 and NET/ROM connections and steers
622 them to the relevant program. There are lots of configuration options
623 you can set here, however they are well covered in the AX25-HOWTO. For
624 our purposes I will show a typical set of parameters. An example is
629 parameters 2 1 6 900 * 15 0
631 default * * * * * * - sysop /spider/src/client client %u ax25
634 parameters 2 1 6 900 * 15 0
636 default * * * * * * 0 root /usr/sbin/node node
639 parameters 2 1 6 900 * 15 0
641 default * * * * * * - sysop /spider/src/client client %u ax25
644 parameters 2 1 6 900 * 15 0
646 default * * * * * * 0 root /usr/sbin/node node
649 parameters 1 10 * * * 3 *
651 default * * * * * * - sysop /spider/src/client client %u ax25
654 parameters 1 10 * * * 3 *
656 default * * * * * * 0 root /usr/sbin/node node
660 There are a few things to take note of here. Firstly, all ax25
661 sections are wrapped in [ ] and all NET/ROM sections are wrapped in
662 < >. Secondly you should be able to see that anyone who forgets to
663 set their callsign in a TNC and tries to connect with the standard
664 NOCALL set into their TNC will not connect, the 'L' means 'lockout'.
665 Lastly and importantly, notice the order of the sections. They are
666 all done in interface order.
669 You should be able to see that the normal line for access to the
670 cluster is like this ..
673 default * * * * * * - sysop /spider/src/client client %u ax25
677 however, if you wish your users to be able to use SSID's on their callsigns ..
680 default * * * * * * - sysop /spider/src/client client %s ax25
684 For most purposes this is not desirable. The only time you probably will
685 need this is when you need to allow other cluster nodes that are using SSID's
686 in. In this case it would probably be better to use the first example and
687 then add a specific line for that node like this:
690 GB7DJK-2 * * * * * * - sysop /spider/src/client client gb7djk-2 ax25
691 default * * * * * * - sysop /spider/src/client client %u ax25
697 For those of you that wish to run the node, you need to set up the
698 node.conf file. There are a couple of additional files, node.perms is
699 very similar to the way ftp permissions are set up in NOS systems and
700 node.motd is the message anyone logging into the node will get.
701 The node.conf file sets all the parameters of the node as you would
702 expect. An example is below ...
705 # /etc/ax25/node.conf - LinuxNode configuration file
709 # Idle timeout (seconds).
713 # Timeout when gatewaying (seconds).
717 # Visible hostname. Will be shown at telnet login.
719 HostName gb7mbc.ampr.org
727 #LocalNet 44.139.8.48/32
729 # Command aliases. See node.conf(5) for the meaning of the uppercase
730 # letters in the name of the alias.
732 ##Alias CAllbook 'telnet %{2:44.17.0.53} 1235 %1 s'
733 #Alias CONVers 'telnet %{2:oh2ti} 3600 "/n %u %{1:139}\n/w *"'
734 #Alias CLuster 'c hkiclh'
735 Alias CONV "telnet lurpac 3600"
736 Alias BBS "c 70cm gb7crv"
737 Alias DXC "telnet localhost 9000"
738 Alias MUD "telnet homer 4000"
739 ##Alias TEMP "finger temp@mary.g6phf"
740 ##Alias TNOS "c ip1 gb7mbc-5"
741 ##Alias TUtor "telnet gb7mbc 3599"
747 # External commands. See node.conf(5) for the meaning of the uppercase
748 # letters in the name of the extcmd.
750 # Flags: 1 Run command through pipe
753 #ExtCmd TPM 3 nobody /usr/bin/finger finger tpm
754 #ExtCmd ECho 1 nobody /bin/echo echo \%U \%u \%S \%s \%P \%p \%R \%r \%T \%t \%\% \%0 \%{1:foobar} \%{2} \%3 \%4 \%5
758 NodeId "\nBARE:GB7MBC-1"
759 #NodeId \033[01;31m***\033[0m
761 # Netrom port name. This port is used for outgoing netrom connects.
769 # The escape character (CTRL-T)
773 # Resolve ip numbers to addresses?
780 #NodePrompt "%s@%h \%i> "
781 NodePrompt "\nBARE:GB7MBC-1 \%i > "
782 #NodePrompt "\a\033[36m%U\033[0m de \033[01;32m#LNODE\033[0m:\033[01;33mOH2BNS-10\033[0m> "
786 This should be fairly obvious I hope.
788 <sect1>Getting it all running
791 Ok, now we have all the relevant files configured, the next step is to get
795 The first thing to do is attach the TNC's. Your TNC's should be in KISS mode
796 and connected to the serial ports involved.
799 You now use the 'kissattach' command to connect the TNC's to the system like this ...
802 kissattach /dev/ttyS0 2m 44.131.96.199
803 kissattach /dev/ttyS1 4m 44.131.96.199
807 Assuming that 44.131.96.199 is your IP address. The devices ttyS0 and ttyS1 are com1 and
808 com2 respectively. Now we can set some parameters ...
811 kissparms -p 2m -t 150 -l 150 -s 50 -r 50
812 kissparms -p 4m -t 150 -l 150 -s 50 -r 50
816 The command 'man kissparms' will give you the explanation of the switches.
819 Now we need to attach the NET/ROM ports in the same way ...
827 All of the above can be put in a file and called from /etc/rc.d/rc.local. Put all
828 the above commands in a file called rc.ax25 and put a line in rc.local to call it.
831 Now you can start the daemons that set everything in motion ...
839 All should now be running. All that remains is to get the node working for telnet
840 connections. If nothing else, this will allow you to connect to the node yourself
841 to check on connection status etc. There are 2 files that need to be edited.
844 First edit /etc/services and add
847 node 3000/tcp #OH2BNS's Node Software
851 Assuming you want it to run on port 3000
854 Now cd /etc/xinetd.d and edit a new file called node. It should look like this ...
858 # unencrypted username/password pairs for authentication.
864 server = /usr/sbin/node
865 log_on_failure += USERID
871 You now need to restart the xinetd daemon. First find out what the PID is
879 You will get a reply something like this ...
882 root 592 0.0 0.1 2256 620 ? S Feb07 0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
886 The PID or Process ID is 592 in this case so now we can issue the command ...
893 All should now be operational and you should be able to log into the node by
894 using a telnet session to the relevant port, like so ...
897 telnet localhost 3000
901 If that works, you are just about there. you should (assuming you have radios connected
902 to the TNC's) be able to connect out to other stations and receive incoming ax25 and
907 <sect1>Allowing ax25 connects from users
910 This is dealt with in the previous section
912 <sect1>Setting up telnet connects (from 1.47 onwards)
915 >From version 1.47 you can choose to allow the perl cluster.pl program to
916 allow connections directly (i.e. not via the <tt>/spider/src/client</tt>
917 interface program). If you are using Windows then this is the only method
918 available of allowing incoming telnet connections.
921 to make the change happen...
924 Having done that, you need to copy the file
925 <em>/spider/perl/Listeners.pm</em> to <em>/spider/local</em> and
926 then edit it. You will need to uncomment the line containing &dquot;0.0.0.0&dquot;
927 and select the correct port to listen on.
929 It comes out of the box looking something like:-
937 Change it so that it looks like this:-
946 Later versions have more comments in the Listeners.pm file that
947 are designed to help you remove the correct '#' character.
950 As standard, the listener will listen on all interfaces simultaneously.
951 If you require more control than this, you can specify each interface
956 ["gb7baa.dxcluster.net", 7300],
957 ["44.131.16.2", 6300],
962 This will only be successful if the IP addresses on each interface are static.
963 If you are using some kind of dynamic IP addressing then the 'default' method
964 is the only one that will work.
967 Restart the cluster.pl program to enable the listener.
970 One important difference with the internal listener is that no echoing
971 is done by the cluster program. Users will need to set 'local-echo' on in
972 their telnet clients if it isn't set automatically (as per the standards).
973 Needless to say this will probably only apply to Windows users.
975 <sect1>Allowing telnet connects from users (before version 1.47 or for special purposes)
978 >From version 1.47 there is a new (more efficient) way of doing this
979 (see previous section) but, if you prefer, the method of doing it described
980 here will continue to work just fine.
983 Allowing telnet connections is quite simple. Firstly you need to add a line
984 in /etc/services to allow connections to a port number, like this ....
987 spdlogin 8000/tcp # spider anonymous login port
991 Then add a line in /etc/inetd.conf like this ....
994 spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
998 Once this is done, you need to restart inetd like this ....
1005 Now login as <em>sysop</em> and cd spider/src. You can test that spider
1006 is accepting telnet logins by issuing the following command ....
1009 ./client login telnet
1013 You should get a login prompt and on issuing a callsign, you will be given
1014 access to the cluster. Note, you will not get a password login. There seems
1015 no good reason for a password prompt to be given so it is not asked for.
1018 Assuming all is well, then try a telnet from your linux console ....
1021 telnet localhost 8000
1025 You should now get the login prompt and be able to login as before.
1028 <sect1>Setting up for AGW Engine (1.47 onwards)
1031 AGW Engine is a Windows based ax25 stack. You can connect to an AGW engine
1032 from Linux as well as Windows based machines.
1035 In order to enable access to an AGW Engine you need to copy
1036 <em>/spider/perl/AGWConnect.pm</em> to <em>/spider/local</em> and edit it.
1037 Specifically you must:-
1040 <item> set <tt>$enable</tt> to 1.
1041 <item> set <tt>$login</tt> and <tt>$passwd</tt> to the values set up in your AGW installation.
1042 If you haven't set any there, then you should not touch these values.
1043 <item> You can connect to a remote AGW engine (ie on some other machine) by changing <tt>$addr</tt>
1044 and <tt>$port</tt> appropriately.
1045 <item> Restart the cluster.pl program
1049 <sect1>Setting up node connects
1052 In order to allow cluster node connections, spider needs to know that the
1053 connecting callsign is a cluster node. This is the case whether the connect
1054 is incoming or outgoing. In spider this is a simple task and can be done in
1058 Later versions of Spider can distinguish different software and treat them
1059 differently. For example, the WCY beacon cannot be handles by AK1A type
1060 nodes as AK1A does not know what to do with PC73. There are 4 different
1061 types of node at present and although they may not have any major
1062 differences at the moment, it allows for compatibility. The 4 types are ...
1065 set/node (AK1A type)
1072 For now, we will assume that the cluster we are going to connect to is an
1076 Start up the cluster as you did before and login as the sysop with client.
1077 The cluster node I am wanting to make a connection to is GB7BAA but you would
1078 obviously use whatever callsign you required. At the prompt type ...
1085 The case does not matter as long as you have a version of DXSpider later than
1086 1.33. Earlier versions required the callsign to be in upper case.
1089 That is now set, it is as simple as that. To prove it, login on yet another
1090 console as sysop, cd to spider/src and issue the command ...
1093 ./client gb7baa (using the callsign you set as a node)
1097 You should get an initialisation string from DXSpider like this ...
1104 If the callsign you just set up as a cluster node is for an incoming connect,
1105 this is all that needs to be done. If the connection is to be outgoing then
1106 a connection script needs to be written.
1109 Sometimes you make a mistake... Honest, it does happen. If you want to make a node
1110 back to being a normal user, regardless
1111 of what type it is, do:
1117 <sect1>Connection scripts
1120 Because DXSpider operates under Linux, connections can be made using just about
1121 any protocol; AX25, NETRom, tcp/ip, ROSE etc are all possible examples.
1122 Connect scripts live in the /spider/connect directory and are simple ascii files.
1123 Writing a script for connections is therefore relatively simple.
1126 The connect scripts consist of lines which start with the following keywords
1131 <tag/#/All lines starting with a <tt>#</tt> are ignored, as are completely
1134 <tag/timeout/<tt>timeout</tt> followed by a number is the number of seconds to wait for a
1135 command to complete. If there is no timeout specified in the script
1136 then the default is 60 seconds.
1138 <tag/abort/ <tt>abort</tt> is a regular expression containing one or more strings to look
1139 for to abort a connection. This is a perl regular expression and is
1140 executed ignoring case.
1142 <tag/connect/<tt>connect</tt> followed by ax25, agw (for Windows users) or telnet and some type dependent
1143 information. In the case of a telnet connection, there can be up to
1145 The first is the ip address or hostname of the computer you wish to
1146 connect to and the second is the port number you want to use (this
1147 can be left out if it is a normal telnet session).
1148 In the case of an ax25 session then this would normally be a call to
1149 ax25_call or netrom_call as in the example above. It is your
1150 responsibility to get your node and other ax25 parameters to work
1151 before going down this route!
1153 <tag/'/<tt>'</tt> is the delimiting character for a word or phrase of an expect/send
1154 line in a chat type script. The words/phrases normally come in pairs,
1155 either can be empty. Each line reads input from the connection until
1156 it sees the string (or perl regular expression) contained in the
1157 left hand string. If the left hand string is empty then it doesn't
1158 read or wait for anything. The comparison is done ignoring case.
1159 When the left hand string has found what it is looking for (if it is)
1160 then the right hand string is sent to the connection.
1161 This process is repeated for every line of chat script.
1163 <tag/client/<tt>client</tt> starts the connection, put the arguments you would want here
1164 if you were starting the client program manually. You only need this
1165 if the script has a different name to the callsign you are trying to
1166 connect to (i.e. you have a script called other which actually
1167 connects to GB7DJK-1 [instead of a script called gb7djk-1]).
1171 There are many possible ways to configure the script but here are three examples,
1172 one for a NETRom/AX25 connect, one for AGW engines and one for tcp/ip.
1176 abort (Busy|Sorry|Fail)
1177 # don't forget to chmod 4775 netrom_call!
1178 connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh
1181 'Connect' 'c gb7dxm'
1182 # you can leave this out if you call the script 'gb7dxm'
1190 abort (Busy|Sorry|Fail)
1191 # this does exactly the same as the previous example
1192 # the '1' is the AGW port number to connect thru for g1tlh
1196 'Connect' 'c gb7dxm'
1197 # you can leave this out if you call the script 'gb7dxm'
1205 connect telnet dirkl.tobit.co.uk
1208 # tell GB7DJK-1 that it is connected to GB7DJK
1209 # you can leave this out if you call this script 'gb7djk'
1210 client gb7djk telnet
1214 Both these examples assume that everything is set up properly at the other end.
1215 You will find other examples in the /spider/examples directory.
1217 <sect1>Starting the connection
1220 You start the connection, from within a sysop enabled cluster login, by typing
1221 in the word <em>connect</em> followed by a script name like this ....
1224 G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
1225 connection to GB7DJK-1 started
1226 G0VGS de GB7MBC 13-Dec-1998 2043Z >
1230 This will start a connection using the script called <em>gb7djk-1</em>. You can
1231 follow the connection by watching the term or console from where you started
1232 <em>cluster.pl</em>. From version 1.47 onwards, you will need to <tt>set/debug connect</tt> first.
1233 You should see something like this ...
1236 <- D G1TLH connect gb7djk-1
1237 -> D G1TLH connection to GB7DJK-1 started
1238 -> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
1240 CONNECT sort: telnet command: dirkl.tobit.co.uk
1241 CHAT "login" -> "gb7djk"
1243 Red Hat Linux release 5.1 (Manhattan)
1244 Kernel 2.0.35 on an i586
1248 CHAT "word" -> "gb7djk"
1250 received "Password: "
1252 Connected to GB7DJK-1, starting normal protocol
1253 <- O GB7DJK-1 telnet
1255 GB7DJK-1 channel func state 0 -> init
1257 <- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
1258 <- D GB7DJK-1 PC38^GB7DJK-1^~
1259 <- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime
1266 With later versions of Spider there is a set/login command for users. This
1267 tells them when a user or node logs in or out. If you do not add a line to
1268 your scripts after the final line (or before the client line which should always
1269 be last if needed) then the login/logout information will be sent to users
1270 <it>before</it> the login actually completes. This means if a node is
1271 unreachable, it will continue sending logins and logouts to users even though it
1272 is not actually connecting. To avoid this use the following line ...
1279 In a script, this might look like ...
1283 abort (Busy|Sorry|Fail)
1284 connect telnet mary 3000
1286 '>' 'telnet 44.131.93.96 7305'
1293 Cluster links in particular suffer greatly from the presence of telnet echo.
1294 This is caused by the telnet negotiation itself and can create at worst severe
1295 loops. At best it creates unnecessary bandwidth and large logfiles! There are
1296 things that can be done to limit this problem but will not always work dependent
1297 on the route taken to connect.
1300 Telnet echo itself should only be a problem if the connection is being made to
1301 the telnet port (23). This port uses special rules that include echo negotiation.
1302 If the connection is to a different port, such as 7300, this negotiation does
1303 not happen and therefore no echo should be present.
1306 Sometimes it is not possible to make a direct connection to another node and this
1307 can cause problems. There is a way of trying to suppress the telnet echo but
1308 this will not always work, unfortunately it is difficult to be more specific.
1309 Here is an example of what I mean ...
1313 abort (Busy|Sorry|Fail)
1314 connect telnet mary.lancs.ac.uk
1317 '\$' 'stty -echo raw'
1318 '\$' 'telnet 44.131.93.96'
1323 So, the first connection is made by Spider. This is fine as Spider uses the
1324 Net_Telnet script from within perl. This actually uses TCP rather than TELNET
1325 so no negotiation will be done on the first connection. Once connected to
1326 mary.lancs.ac.uk, the command is sent to suppress echo. Now a telnet is made
1327 to a cluster node that is accepting connections on port 23. The problem with
1328 this link is that the negotiation is made by the remote machine, therefore you
1329 have no control over it. The chances are that this link will create echo and
1330 there will be no way you can stop it.
1333 <sect1>Autostarting the cluster
1336 Ok, you should now have DXSpider running nicely and allowing connects by cluster
1337 nodes or users. However, it has to be shutdown and restarted manually. It
1338 would be much easier to have it start automatically.
1341 This is not only a way to start the cluster automatically, it also works as a
1342 watchdog, checking the sanity of DXSpider and respawning it should it crash for
1343 any reason. Before doing the following, shutdown the cluster as you did earlier.
1346 Login as root and bring up the /etc/inittab file in your favourite editor. Add
1347 the following lines to the file near the end ...
1350 ##Start DXSpider on bootup and respawn it should it crash
1351 DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
1355 This line works fine for RedHat distributions. It is also fine for SuSE up to
1356 7.0. From SuSE 7.1 you need to add runlevels 2 and 5 like this ...
1359 DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
1363 The line required for Slackware distributions is slightly different. My thanks to
1364 Aurelio, PA3EZL for this information.
1367 DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
1371 This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart
1372 it should it crash for any reason.
1375 NB: It should be noted that /dev/tty7 is only an example. Some SuSE systems will
1376 only accept upto tty6. It really does not matter which tty you run it on.
1379 As root type the command <em>telinit q</em>. DXSpider should start up
1380 immediately. You will see the output on tty7 and if you login as <em>sysop</em>
1381 you should find everything running nicely.
1383 <sect>Microsoft Windows Installation
1390 What you'll be left with once you've followed these instructions
1391 is (hopefully) a working DX Spider v1.50 system that is capable
1392 of accepting or originating "internet" connections, plus inbound
1393 and outbound AX.25 and TCP/IP radio connections.
1395 On the other hand, you may have an enquiring mind, or better yet,
1396 may be looking for a useful way of connecting your current
1397 (perhaps) AK1A cluster "to the internet" via some networking
1398 mechanism (BPQEther, etc) or other. I won't be producing
1399 instructions for the latter case, because I don't have an AK1A to
1400 play with. But someone might ...
1402 Whatever, this document is intended to get you started with DX
1403 Spider in a Microsoft Windows ™ environment. It's not
1404 intended to teach you anything other than how to perform a
1405 minimum configuration of a DX Spider installation and have it
1406 able to connect across "the internet" to other DX Clusters, while
1407 accepting inbound TELNET and radio connections.
1409 <sect1>The requirements
1412 The very first things you're going to need are (in order of
1416 <item>A cup of good, strong tea
1417 <item>A supported Windows platform with an internet connection so you can
1418 download the necessary software bits and bobs directly to it. There are other ways, but this is preferable.
1419 <item>Another cup of good, strong tea
1420 <item>If all goes according to plan, about an hour to spare
1421 <item>Plenty of good, strong tea
1427 The platform I used to generate these instructions was a
1428 "vanilla" Microsoft Windows Me 4.90.3000 system, with a 700MHz
1429 AMD Athlon processor and 96 Mb memory. I've also personally
1430 verified that it runs on my laptop (Pentium 266MHz, 32 Mb memory,
1431 Windows 98 SE v4.10.2222 A) and a computer that I assembled from
1432 a random pile of junk (AMD K6-2 333MHz, 64 Mb memory, Windows 98
1433 v4.10.1998). As a result, I have reason to believe that what I'm
1434 about to describe will perform equally on any 32-bit MS Windows
1435 environment with 32 Mb of memory.
1437 Because of the changes that have recently been made to the core
1438 "cluster.pl" module and the introduction of a very lightweight
1439 "winclient.pl", I have a sneaking suspicion that this will now
1440 run on any platform that has reasonably complete support for
1441 Perl. Is there someone out there with both an enquiring mind and
1442 (say) a Macintosh, for instance?
1444 Please bear in mind, though, that my instructions relate solely
1445 to how to get this going under a Microsoft Windows environment,
1446 and I have zero intention of trying to make them say otherwise.
1451 Install your chosen Perl environment. Unless you have a very good
1452 reason for not doing so, I strongly suggest that you use
1453 ActivePerl v5.6. For my testing & development, I used build 623.
1454 (A recent installation used the newer ActivePerl v5.6.1, build
1455 633 without any noticable difficulty.) You can get this from:
1456 <htmlurl url="http://www.activestate.com/Products/ActivePerl/Download.html"
1457 name="http://www.activestate.com/Products/ActivePerl/Download.html">
1459 The link takes you to an initial page of System Requirements and
1460 Software Prerequisites. If you do not have it already installed,
1461 you can download and install the Windows Installer 2.0 for a Win98
1462 installation. Be forewarned, you will have to reboot your PC at the
1463 completion of the installer's installation.
1465 If you already have the installer on your PC, simply click on the
1466 Next arrow at the bottom of the page. Two clicks will finally get
1467 you to the actual download page. The MSI version of Build 633 is
1468 now 8.6MB in size, so make that a big cup of tea or coffee if you're
1469 on a slow dial-up connection.
1471 During installation, please ensure that you do choose the options
1472 to "Add Perl to the PATH environment variable" and "Create Perl
1473 file extension association"; it will make your life so much
1474 easier. Once the installation is finished, be sure to reboot your
1475 PC. You probably won't be told anywhere else that this needs to
1476 be done now, but it does. Really.
1478 Once you've rebooted, open a "DOS box" (Start > Run > command
1479 might do it, if you can't find it elsewhere) and from wherever it
1480 lands, type PERL -v <ENTER> (it's better if that's a lower-case
1481 'v', because an upper-case 'V' means something else. You should
1482 be rewarded with some interesting information about your Perl
1483 installation. If you're not, you must go back to the beginning
1484 and discover what went wrong and fix it. It's pointless to
1485 proceed unless this simple check is passed. Assuming it did work,
1486 you may now move on.
1488 <sect1>Additional packages
1491 Some extensions ("packages") need to be added to the base Perl
1492 distribution, and we'll do this next. If you're using the Perl I
1493 recommended, and don't know any better for yourself, then just
1494 blindly following these instructions will work just fine. If that
1495 didn't describe you, then you're on your own.
1497 Visit the following URL:
1499 <htmlurl url="http://www.activestate.com/PPMPackages/zips/6xx-builds-only/"
1500 name="http://www.activestate.com/PPMPackages/zips/6xx-builds-only/">
1502 and download the following files:-
1512 If this is a new installation, now would also be a good time to
1513 install a copy of WinZip on your PC. Make yourself a convenient
1514 directory to unpack all of these zip files into (I put mine in
1515 "D:\ppm>" but "C:\ppm" works just as well.) and do the following
1516 (the bits you type in are blue ). You can upzip all of the files into
1517 the same directory. When prompted, simply overwrite the Readme file
1518 from each zip package. Note that where these files land will be
1519 directly related to where you chose to install your ActivePerl
1520 (mine, as you can probably guess from what follows, went into "D:\Perl"):-
1523 D:\ppm>ppm install Data-Dumper.ppd
1524 Installing package 'Data-Dumper.ppd'
1525 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.bs
1526 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.dll
1527 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.exp
1528 Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.lib
1529 Installing D:\Perl\html\site\lib\auto\Data\Dumper\Dumper.html
1530 Installing D:\Perl\site\lib\Data\Dumper\Dumper.pm
1531 Writing D:\Perl\site\lib\auto\Data\Dumper\Dumper.packlist
1535 I'm not going to bother you with exhaustive details of the rest
1536 of them, but suffice it to say you need to:
1539 ppm install DB_File.ppd
1540 ppm install Net-Telnet.ppd
1541 ppm install TimeDate.ppd
1542 ppm install Time-HiRes.ppd
1545 If all that seemed to work OK, time to move along. Before anyone
1546 who is familiar with PPM tells me that we didn't need to download
1547 and keep those files locally, I knew that. I also knew that PPM
1548 is sometimes awkward to configure via firewalls, and that
1549 sometimes the repositories don't always work the way we'd hope. I
1550 do it that way because it suits me.
1552 <sect1>Getting Spider
1555 Get the current version of the DX Spider distribution. This needs
1556 to be v1.50 or later. You've got two ways (currently) of getting
1557 this; either get a CVS update from sourceforge (if you don't know
1558 what this is, then it isn't for you) or get the latest "official"
1561 <htmlurl url="http://www.dxcluster.org/download/index.html" name="http://www.dxcluster.org/download/index.html">
1563 or if you want the lastest snapshot of CVS version (which is produced
1566 <htmlurl url="http://www.dxcluster.org/download/CVSlatest.tgz" name="http://www.dxcluster.org/download/CVSlatest.tgz">
1568 This is generally the best one to go for as it is completely up to
1569 date. However, there is always the very slight chance that it might
1570 unstable. Generally, there will be a note on the website if this is
1574 The only difference between "CVSlatest.tgz" and the latest
1575 "official" release version is that it is more up to date. <bf>Do not confuse
1576 the "CVSlatest.tgz" file with "Downloading from Sourceforge with CVS" - they
1577 are two quite different things.</bf> "Downloading from Sourceforge with CVS" is
1578 explained in a section within the Admin manual.
1581 If you go down the CVS route (ie installing WinCVS as explained in the Admin
1582 manual and downloaded from sourceforge), then everything will be nicely
1583 installed on your local disk. If you got the CVSlatest.tgz file, unzip
1584 (<htmlurl url="http://www.winzip.com" name="winzip">) it to "C:\".
1585 This is an important point since paths are included within the .tgz
1586 file. Make sure you unzip to the root directory of whichever drive you use...
1587 "C:\" or "D:\" or .., not "C:\spider." If you double click on CVSlatest.tgz,
1588 WinZip should open with a dialogue box that says the Archive contains a single
1589 file (CVSlatest.tar) and asks whether WinZip should decompress it to a
1590 temporary fold and then open it. Say "Yes" and then you will get the typical
1591 Classical WinZip listing of files ready for extraction. Remember, extract
1592 them to your desired root directory ("C:\" or "D:\" or ...). The following
1593 examples assume that you put it on drive "C:\", for convenience.
1595 <sect>Installing the software
1598 At this point you will need to create 2 additional directories under
1599 "C:\Spider." Make directories "C:\spider\local" and "C:\spider\local_cmd".
1600 If "C:\spider" is missing, go back and figure out why, because it shouldn't be.
1602 Now create your own local copy of the DXVars.pm file by:-
1605 copy c:\spider\perl\DXVars.pm.issue
1606 c:\spider\local\DXVars.pm
1609 Now you'll need to edit this file using a text editor like Notepad. If nothing
1610 else, you can simply
1622 to bring up an editor window containing the file. As an absolute
1623 minimum you must adjust the following items in DXVars.pm:-
1626 <item> $mycall - Should hold the callsign of your DX Cluster
1627 <item> $myname - The SysOp's first name
1628 <item> $myalias - the SysOp's callsign. Cannot be the same as $mycall!
1629 <item> $myqth - The station's geographical location (QTH).
1630 <item> $mylatitude - The station latitude in degrees and decimal fractions
1631 <item> $mylongitude - The station longitude in degrees and decimal fractions
1632 <item> $mylocator - The Maidenhead (or QRA) locator of the station
1635 You really also ought to update the $myqth and $myemail variables. And
1636 unless you are absolutely certain you know what you're doing, you
1637 should change nothing else in this file. Note that if you use an "@" or
1638 a "$" character in one of the above strings (typically in $myemail) you must
1639 write them as "\@" or "\$".
1641 <sect1>Incoming telnets
1644 If you want to enable inbound "TELNET" connections (or you are running
1645 Windows 98, NT, 2000 or XP), you've got a little more work to do. From a
1646 handy "DOS box" that's not doing anything else, do the following:-
1649 copy \spider\perl\Listeners.pm \spider\local
1651 notepad listeners.pm
1654 The following line need attention:-
1657 # ["0.0.0.0", 7300],
1660 On my machine, I've simply uncommented the "0.0.0.0" entry by
1661 removing the '#' from the front of the line.
1663 <bf>You MUST carry out this step if you are
1664 running on a Windows 98, NT, 2000 or XP based system</bf>
1666 If you don't have a static hostname for your machine, and you
1667 intend to allow folk to connect to your machine across the
1668 internet, then I'd suggest you pay a visit to www.dyndns.org and
1669 create one for yourself. While it's free, it will take a modest
1670 amount of effort on your part to read, understand and
1671 implement what needs to be done to set this up.
1673 <p>If your machine is connected to the internet <bf>and</bf> you don't
1674 want to allow your machine to be visible to the outside world you
1675 should change the "0.0.0.0" to "127.0.0.1" [which is
1676 "localhost"]. This will then only allow connections from inside your
1677 machine. As was said earlier: if you aren't running Win9x (or you want
1678 to use DXTelnet or somesuch), then you need to have the machine
1679 listening at least to "127.0.0.1" ("0.0.0.0" means <bf>all</bf> IP
1682 <sect1>The AGW packet engine
1685 On the assumption that you'll be using the SV2AGW Packet Engine
1686 to interface your radios to the cluster, it would be a good idea to
1687 download the Packet Engine software! You can get this software from:
1689 <htmlurl url="http://www.raag.org/sv2agw/agwpe.zip" name="http://www.raag.org/sv2agw/agwpe.zip">
1691 Depending upon your TNCs, you may also need to get:
1693 <htmlurl url="http://www.raag.org/sv2agw/drivers.zip" name="http://www.raag.org/sv2agw/drivers.zip">
1695 A couple of the tools:
1697 <htmlurl url="http://www.raag.org/sv2agw/agwterm.zip" name="http://www.raag.org/sv2agw/agwterm.zip">
1699 <htmlurl url="http://www.raag.org/sv2agw/agwmonitor.zip" name="http://www.raag.org/sv2agw/agwmonitor.zip">
1701 will also help with troubleshooting of the RF links themselves.
1703 Install and configure AGWPE. You should now create your own local copy of
1707 copy c:\spider\perl\AGWConnect.pm
1708 c:\spider\local\AGWConnect.pm
1714 notepad AGWConnect.pm
1717 to bring up an editor window containing the file. You must
1718 consider adjusting the following items in AGWConnect.pm:-
1721 <item>$enable - set to '1' to enable AGWPE interface
1722 <item>$login - the login ID you chose when you set up the SV2AGW security :-)
1723 <item>$passwd - password that matches $login
1726 The login ID and passwd only need to be set if you are accessing AGW separately
1727 via its web interface. This interface is normally not needed for use with DXSpider.
1729 <sect1>Setting up the initial user files
1732 Next you need to create the initial user files, etc. A tool is
1733 supplied which will do this for you. To run the tool:-
1737 perl create_sysop.pl
1740 If all goes according to plan, you will see no output from this
1741 program, and after a brief wait, your DOS prompt will be
1744 Depending on how brave you are, you might now care to try the
1751 If you did everything you were told, your DOS window will now
1752 hold a display which looks something like:-
1755 DXSpider DX Cluster Version 1.50
1756 Copyright (c) 1998-2002 Dirk Koopman G1TLH
1757 loading prefixes ...
1758 loading band data ...
1759 loading user file system ...
1760 starting listeners ...
1761 Internal port: localhost 27754
1763 reading in duplicate spot and WWV info ...
1764 reading existing message headers ...
1768 @msg = 0 before delete
1769 @msg = 0 after delete
1770 reading cron jobs ...v cron: reading /spider/cmd/crontab
1771 cron: adding 1 0 * * 0
1772 DXUser::export("$main::data/user_asc")
1773 reading database descriptors ...
1774 doing local initialisation ...
1775 orft we jolly well go ...
1779 Now, if that's what you've got, you are very nearly home and dry
1780 (in as far as these particular experiments are concerned, anyhow)
1782 If you are running Windows 9x you can access your new cluster (from
1783 the local machine) by finding yourself another "DOS box" and doing the
1791 If you are running Windows NT, 2000 or XP then winclient.pl does not
1792 work. We don't know why other than this seems to be some kind of
1793 incomaptibility in perl. You can achieve the same thing by telnetting
1794 to the port you defined in Listeners.pm (7300 as default), thus:-
1798 telnet localhost 7300
1801 On getting the <bf>login:</bf> prompt, enter your sysop callsign (the one you
1802 put in DXVars.pm as $myalias).
1804 <p>I would recommend <bf>strongly</bf> that you obtain a better telnet
1805 client than that which comes with windows (I use <htmlurl
1806 url="http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html"
1809 <p>Anyway, if you are rewarded with a display which looks something like:-
1812 Hello Iain, this is GB7SJP in Amersham, Bucks running DXSpider V1.50
1813 Cluster: 1 nodes, 1 local / 1 total users Max users 2 Uptime 0 00:00
1814 M0ADI de GB7SJP 4-Mar-2001 1511Z >
1817 You've arrived. Try some commands, and see how they feel. (In
1818 case you were wondering, "Iain", "M0ADI" and "GB7SJP" all came
1819 from the version of DXVars.pm that was on the machine when I
1820 started the winclient.pl)
1822 <p>The interface is very basic. It is a simple command line. There are
1823 better looking interfaces. Most of the "standard" logging and DX
1824 Cluster access programs that are capable of connecting via a TCP or
1825 telnet connection will work as a "Sysop Console" client. You connect
1826 to "localhost" on the port that you defined in Listeners.pm (usually
1827 7300). I recommend packages like <htmlurl
1828 url="http://www.qsl.net/wd4ngb/telnet.htm" name="DXTelnet">.
1830 <sect1>Connecting to other clusters
1833 If you want to connect this to another cluster, then you'll want to
1834 negotiate a link with someone. For experimental purposes, I'm happy to
1835 allow folk to connect to GB7DXA (spud.ath.cx), on the understanding
1836 that the system may or may not be there and may or may not be
1837 connected to anything particularly useful at any given moment. Contact
1838 me by <htmlurl url="mailto:g0rdi@blacksheep.org" name="Email"> if you
1839 want me to set up a connection for you.
1841 <sect>General Information
1844 The following relates to all versions of DXSpider and is not platform related.
1846 <sect1>The crontab file
1849 Login as <em>sysop</em> and create a file in /spider/local_cmd called crontab.
1850 Edit it with your favourite editor and add a line like this (I have included
1854 # check every 10 minutes to see if gb7xxx is connected and if not
1855 # start a connect job going
1857 0,10,20,30,40,50 * * * * start_connect('gb7xxx') unless connected('gb7xxx')
1861 The callsign involved will be the callsign of the cluster node you are
1862 going to connect to. This will now check every 10 minutes to see if
1863 gb7xxx is connected, if it is then nothing will be done. If it is not,
1864 then a connect attempt will be started.
1867 There are probably lots of other things you could use this crontab file for.
1868 If you want to know more about it, look at the
1869 <htmlurl url="http://www.dxcluster.org/main/cron.html" name="DXSpider"> website
1870 at the cron page where it is explained more fully.