The DXSpider Installation Manual v1.49
Iain Philipps, G0RDI (g0rdi@77hz.com) and Ian Maude, G0VGS,
- (ianmaude@btinternet.com)
- November 2001 revision 1.0
+ (g0vgs@gb7mbc.net)
+ December 2001 revision 1.1
A reference for SysOps of the DXSpider DXCluster program.
______________________________________________________________________
5. Installing the software
- 5.1 The AGW packet engine
- 5.2 Setting up the initial user files
- 5.3 Incoming telnets
+ 5.1 Incoming telnets
+ 5.2 The AGW packet engine
+ 5.3 Setting up the initial user files
5.4 Connecting to other clusters
6. General Information
In addition to the standard Red Hat distribution you will require the
- following modules from http://www.cpan.org/CPAN.html ...
+ following modules from http://www.cpan.org/CPAN.html , please note
+ however that with later versions of perl, some of these modules may be
+ included with the distribution. Get the modules anyway and try to
+ install as below. If they complain, they are probably already a part
+ of your perl distribution.
-
-
-
-
+
If you do not have the command groupadd available to you simply add a
line in /etc/group by hand.
+
You also need to add some others to the group, including your own
callsign (this will be used as an alias) and root. The finished line
in /etc/group should look something like this
The next step is to set the permissions on the Spider directory tree
and files ....
-
-
- # chown -R sysop.spider spider
- # find . -type d -exec chmod 2775 {} \;
- # find . -type f -exec chmod 775 {} \;
+ # chown -R sysop.spider spider
+ # find . -type d -exec chmod 2775 {} \;
+ # find . -type f -exec chmod 775 {} \;
Using the distributed DXVars.pm as a a template, set your cluster
callsign, sysop callsign and other user info to suit your own
- environment. Note that this a perl file which will be parsed and
- executed as part of the cluster. If you get it wrong then perl will
- complain when you start the cluster process. It is important only to
- alter the text of any section. Some of the lines look a little odd.
- Take this line for example ....
+ environment.
- $myemail = "ianmaude\@btinternet.com";
- There appears to be an extra slash in there. However this has to be
- there for the file to work so leave it in.
+ $mycall = "GB7DJK";
+
+
+
+
+
+ This is the call sign of your cluster. If you use an SSID then
+ include it here also.
+
+
+
+ $myalias = "G1TLH";
+
+
+
+ This is the sysop user callsign, normally your own.
PLEASE USE CAPITAL LETTERS FOR CALLSIGNS
+ Note that this a perl file which will be parsed and executed as part
+ of the cluster. If you get it wrong then perl will complain when you
+ start the cluster process. It is important only to alter the text of
+ any section. Some of the lines look a little odd. Take this line for
+ example ....
+
+ $myemail = "ianmaude\@btinternet.com";
+
+
+ There appears to be an extra slash in there. However this has to be
+ there for the file to work so leave it in.
+
+
DON'T alter any file in /spider/perl, they are overwritten with every
release. Any files or commands you place in /spider/local or
/spider/local_cmd will automagically be used in preference to the ones
- $ ./cluster.pl
- DXSpider DX Cluster Version 1.47
- Copyright (c) 1998 Dirk Koopman G1TLH
- loading prefixes ...
- loading band data ...
- loading user file system ...
- starting listener ...
- reading existing message headers
- reading cron jobs
- orft we jolly well go ...
+
+ $ ./cluster.pl
+ DXSpider DX Cluster Version 1.47
+ Copyright (c) 1998 Dirk Koopman G1TLH
+ loading prefixes ...
+ loading band data ...
+ loading user file system ...
+ starting listener ...
+ reading existing message headers
+ reading cron jobs
+ orft we jolly well go ...
$ ./client
+
+
+
This should log you into the cluster as the sysop under the alias
callsign we set earlier. In this case the callsign is G0VGS. The
cluster callsign is set in the DXVars.pm file in /spider/local. In
+
If you do, congratulations! If not, look over the instructions again,
you have probably missed something out. You can shut spider down
again with the command ....
o cp perl/DXVars.pm.issue local/DXVars.pm (sysop)
-
o cd to /spider/local and edit DXVars to set your details (sysop)
o cd ../perl (sysop)
o ./cluster.pl (sysop)
+
Spider should now be running and you should be able to login using the
client program.
o killall -HUP inetd (root)
+
Spider should now be able to accept logins via telnet, netrom and
ax25.
+
or, if you wish your users to be able to use SSID's on their callsigns
..
+
default * * * * * * - sysop /spider/src/client client %s ax25
+
For most purposes this is not desirable. The only time you probably
will need this is when you need to allow other cluster nodes that are
using SSID's in. In this case it would probably be better to use the
spdlogin 8000/tcp # spider anonymous login port
-
-
-
Then add a line in /etc/inetd.conf like this ....
-
Now login as sysop and cd spider/src. You can test that spider is
accepting telnet logins by issuing the following command ....
./client login telnet
+
+
+
+
You should get a login prompt and on issuing a callsign, you will be
given access to the cluster. Note, you will not get a password login.
There seems no good reason for a password prompt to be given so it is
killall -HUP inetd
-
-
-
to make the change happen...
-
-
-
-
- @listen = (
- ["gb7baa.dxcluster.net", 8000],
- ["44.131.16.2", 6300],
- );
+ @listen = (
+ ["gb7baa.dxcluster.net", 8000],
+ ["44.131.16.2", 6300],
+ );
installation. If you haven't set any there, then you should not
touch these values.
+
o You can connect to a remote AGW engine (ie on some other machine)
by changing $addr and $port appropriately.
- set/node (AK1A type)
- set/spider
- set/dxnet
- set/clx
+ set/node (AK1A type)
+ set/spider
+ set/dxnet
+ set/clx
-
You should get an initialisation string from DXSpider like this ...
unset/node gb7baa
+
+
+
3.6. Connection scripts
Because DXSpider operates under Linux, connections can be made using
There are many possible ways to configure the script but here are
three examples, one for a NETRom/AX25 connect, one for AGW engines and
one for tcp/ip.
+
+
+
timeout 60
abort (Busy|Sorry|Fail)
# don't forget to chmod 4775 netrom_call!
client gb7djk telnet
-
-
-
Both these examples assume that everything is set up properly at the
other end. You will find other examples in the /spider/examples
directory.
+
This will start a connection using the script called gb7djk-1. You
can follow the connection by watching the term or console from where
you started cluster.pl. From version 1.47 onwards, you will need to
-
- <- D G1TLH connect gb7djk-1
- -> D G1TLH connection to GB7DJK-1 started
- -> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
- timeout set to 15
- CONNECT sort: telnet command: dirkl.tobit.co.uk
- CHAT "login" -> "gb7djk"
- received "
- Red Hat Linux release 5.1 (Manhattan)
- Kernel 2.0.35 on an i586
- "
- received "login: "
- sent "gb7djk"
- CHAT "word" -> "gb7djk"
- received "gb7djk"
- received "Password: "
- sent "gb7djk"
- Connected to GB7DJK-1, starting normal protocol
- <- O GB7DJK-1 telnet
- -> B GB7DJK-1 0
- GB7DJK-1 channel func state 0 -> init
- <- D GB7DJK-1
- <- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
- <- D GB7DJK-1 PC38^GB7DJK-1^~
- <- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime
- 0 00:00^5447^~
- etc
+ <- D G1TLH connect gb7djk-1
+ -> D G1TLH connection to GB7DJK-1 started
+ -> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
+ timeout set to 15
+ CONNECT sort: telnet command: dirkl.tobit.co.uk
+ CHAT "login" -> "gb7djk"
+ received "
+ Red Hat Linux release 5.1 (Manhattan)
+ Kernel 2.0.35 on an i586
+ "
+ received "login: "
+ sent "gb7djk"
+ CHAT "word" -> "gb7djk"
+ received "gb7djk"
+ received "Password: "
+ sent "gb7djk"
+ Connected to GB7DJK-1, starting normal protocol
+ <- O GB7DJK-1 telnet
+ -> B GB7DJK-1 0
+ GB7DJK-1 channel func state 0 -> init
+ <- D GB7DJK-1
+ <- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
+ <- D GB7DJK-1 PC38^GB7DJK-1^~
+ <- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime
+ 0 00:00^5447^~
+ etc
This means if a node is unreachable, it will continue sending logins
and logouts to users even though it is not actually connecting. To
avoid this use the following line ...
-
-
-
-
-
-
-
-
In a script, this might look like ...
+
So, the first connection is made by Spider. This is fine as Spider
uses the Net_Telnet script from within perl. This actually uses TCP
rather than TELNET so no negotiation will be done on the first
automatically.
+
This is not only a way to start the cluster automatically, it also
works as a watchdog, checking the sanity of DXSpider and respawning it
should it crash for any reason. Before doing the following, shutdown
This line works fine for RedHat distributions. It is also fine for
SuSE up to 7.0. From Suse 7.1 you need to add runlevels 2 and 5 like
this ...
+
+
+
DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
download the necessary software bits and bobs directly to it. There
are other ways, but this is preferable.
-
o Another cup of good, strong tea
o If all goes according to plan, about an hour to spare
+
I'm not going to bother you with exhaustive details of the rest of
them, but suffice it to say you need to:
because it suits me.
-
-
-
4.6. Getting Spider
Get the current version of the DX Spider distribution. This needs to
be v1.47 or later. You've got two ways (currently) of getting this;
either get a CVS update from sourceforge (if you don't know what this
- is, then it isn't for you) or get my package from:-
+ is, then it isn't for you) or get the latest "official" release from:-
- http://www.dcc.rsgb.org/WinSpider.zip
+ http://www.dxcluster.org/download/index.html
- or if you want the lastest CVS version (which is produced every night)
+ or if you want the lastest snapshot of CVS version (which is produced
+ every night):-
http://www.dxcluster.org/download/CVSlatest.tgz
- If you went down the CVS route, then everything will be nicely set out
- on your local disk. If you got the ZIP file, unpack it to somewhere
+ This is generally the best one to go for as it is completely up to
+ date. However, there is always the very slight chance that it might
+ unstable. Generally, there will be a note on the website if this is
+ the case.
+
+
+ The only difference between "CVSlatest.tgz" and the latest "official"
+ release version is that it is more up to date. Don't confuse this TGZ
+ file with "Downloading from Sourceforge with CVS" - they are two quite
+ different things.
+
+
+ If you went down the CVS route (ie installed wincvs and downloaded
+ from sourceforge), then everything will be nicely set out on your
+ local disk. If you got the TGZ file, unpack it to somewhere
convenient. The following examples assume that you put it on drive
"C:\", for convenience.
- NOTE: This distribution method will go away as soon as the first v1.47
- tarball is released. You can use WinZip to unpack that, and my life
- will be made easier by not needing to keep this .ZIP file updated.
+
+ You will need winzip to manipulate the TGZ files (they are bit like
+ ZIP files) if you are not using CVS.
5. Installing the software
- Ensure that your CVS session or your unZIPped file have left you with
- a directory "C:\spider\local"; if not, go to "C:\spider\" and create
- one. If "C:\spider" is missing, go back and figure out why, because it
- shouldn't be.
+ Ensure that your CVS session or your WINunZIPped file have left you
+ with a directory "C:\spider\local" and C:\spider\local_cmd"; if not,
+ go to "C:\spider\" and create them. If "C:\spider" is missing, go back
+ and figure out why, because it shouldn't be.
+
Now create your own local copy of the DXVars.pm file by:-
o $mycall - Should hold the callsign of your DX Cluster
-
o $myname - The SysOp's first name
o $myalias - the SysOp's callsign. Cannot be the same as $mycall!
- You really also ought to update the $mylatitude, $mylongitude, $myqth
- and $myemail variables. And unless you are absolutely certain you know
- what you're doing, you should change nothing else in this file.
+ o $myqth - The station's geographical location (QTH).
+
+ o $mylatitude - The station latitude in degrees and decimal fractions
+
+ o $mylongitude - The station longitude in degrees and decimal
+ fractions
+
+ o $mylocator - The Maidenhead (or QRA) locator of the station
+
+ You really also ought to update the $myqth and $myemail variables. And
+ unless you are absolutely certain you know what you're doing, you
+ should change nothing else in this file. Note that if you use an "@"
+ or a "$" character in one of the above strings (typically in $myemail)
+ you must write them as "\@" or "\$".
+
+
+
+ 5.1. Incoming telnets
+
+ If you want to enable inbound "TELNET" connections (or you are running
+ Windows NT, 2000 or XP), you've got a little more work to do. From a
+ handy "DOS box" that's not doing anything else, do the following:-
+
+
+
+
+
+ copy \spider\perl\Listeners.pm \spider\local
+ cd \spider\local
+ notepad listeners.pm
+
+
+
+
+ The following lines need attention:-
+
+
+
+ ["0.0.0.0", 7300],
+
+
- 5.1. The AGW packet engine
+ On my machine, I've simply uncommented the "0.0.0.0" entry by removing
+ the '#' from the front of the line.
+
+ You MUST carry out this step if you are running on a Windows NT, 2000
+ or XP based system
+
+ If you don't have a static hostname for your machine, and you intend
+ to allow folk to connect to your machine across the internet, then I'd
+ suggest you pay a visit to www.dyndns.org and create one for yourself.
+ While it's free, it will take a modest an amount of effort on your
+ part to read, understand and implement what needs to be done to set
+ this up.
+
+
+ If your machine is connected to the internet and you don't want to
+ allow your machine to be visible to the outside world you should
+ change the "0.0.0.0" to "127.0.0.1" [which is "localhost"]. This will
+ then only allow connections from inside your machine. As was said
+ earlier: if you aren't running Win9x (or you want to use DXTelnet or
+ somesuch), then you need to have the machine listening at least to
+ "127.0.0.1" ("0.0.0.0" means all IP addresses).
+
+
+ 5.2. The AGW packet engine
On the assumption that you'll be using the SV2AGW Packet Engine to
interface your radios to the cluster, you should now create your own
o $passwd - password that matches $login
- 5.2. Setting up the initial user files
+ 5.3. Setting up the initial user files
Next you need to create the initial user files, etc. A tool is
supplied which will do this for you. To run the tool:-
-
- perl cluster.pl
+ perl cluster.pl
+
Now, if that's what you've got, you are very nearly home and dry (in
as far as these particular experiments are concerned, anyhow)
- To access your new cluster (from the local machine) find yourself
- another "DOS box" and do the following:-
+ If you are running Windows 9x you can access your new cluster (from
+ the local machine) by finding yourself another "DOS box" and doing the
+ following:-
- If you are rewarded with a display which looks something like:-
-
-
-
- Hello Iain, this is GB7SJP in Amersham, Bucks running DXSpider V1.47
- Cluster: 1 nodes, 1 local / 1 total users Max users 2 Uptime 0 00:00
- M0ADI de GB7SJP 4-Mar-2001 1511Z >
-
-
+ If you are running Windows NT, 2000 or XP then winclient.pl does not
+ work. We don't know why other than this seems to be some kind of
+ incomaptibility in perl. You can achieve the same thing by telnetting
+ to the port you defined in Listeners.pm (7300 as default), thus:-
- You've arrived. Try some commands, and see how they feel. (In case you
- were wondering, "Iain", "M0ADI" and "GB7SJP" all came from the version
- of DXVars.pm that was on the machine when I started the winclient.pl)
+ Menu->Start->Run
+ telnet localhost 7300
- 5.3. Incoming telnets
- If you want to enable inbound "TELNET" connections, you've got a
- little more work to do. From a handy "DOS box" that's not doing
- anything else, do the following:-
+ On getting the login: prompt, enter your sysop callsign (the one you
+ put in DXVars.pm as $myalias).
- copy \spider\perl\listeners.pm \spider\local
- cd \spider\local
- notepad listeners.pm
+ I would recommend strongly that you obtain a better telnet client than
+ that which comes with windows (I use PuTTY).
+ Anyway, if you are rewarded with a display which looks something
+ like:-
- The following lines need attention:-
+ Hello Iain, this is GB7SJP in Amersham, Bucks running DXSpider V1.47
+ Cluster: 1 nodes, 1 local / 1 total users Max users 2 Uptime 0 00:00
+ M0ADI de GB7SJP 4-Mar-2001 1511Z >
- ["0.0.0.0", 7300],
+ You've arrived. Try some commands, and see how they feel. (In case you
+ were wondering, "Iain", "M0ADI" and "GB7SJP" all came from the version
+ of DXVars.pm that was on the machine when I started the winclient.pl)
- On my machine, I've simply uncommented the "0.0.0.0" entry by removing
- the '#' from the front of the line.
- If you don't have a static hostname for your machine, and you intend
- to allow folk to connect to your machine across the internet, then I'd
- suggest you pay a visit to www.dyndns.org and create one for yourself.
- While it's free, it will take a modest an amount of effort on your
- part to read, understand and implement what needs to be done to set
- this up.
+ The interface is very basic. It is a simple command line. There are
+ better looking interfaces. Most of the "standard" logging and DX
+ Cluster access programs that are capable of connecting via a TCP or
+ telnet connection will work as a "Sysop Console" client. You connect
+ to "localhost" on the port that you defined in Listeners.pm (usually
+ 7300). I recommend packages like DXTelnet.
5.4. Connecting to other clusters
+
+
The callsign involved will be the callsign of the cluster node you are
going to connect to. This will now check every 10 minutes to see if
gb7xxx is connected, if it is then nothing will be done. If it is
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
projects / spider.git / blobdiff