<!-- Title information -->
-<title>The DXSpider Installation Manual v1.48</title>
+<title>The DXSpider Installation Manual v1.49</title>
<author>Iain Philipps, G0RDI (g0rdi@77hz.com) and
-Ian Maude, G0VGS, (ianmaude@btinternet.com)</author>
-<date>Version 1.48, September 2001 revision 1.0</date>
+Ian Maude, G0VGS, (g0vgs@ea1dav.net)</author>
+<date>December 2001 revision 1.1</date>
<abstract>
A reference for SysOps of the DXSpider DXCluster program.
that you use at least version 5.005_03 as this is the version being used
in the development of Spider.
-<P>In addition to the standard Red Hat distribution you will require the
-following modules from <htmlurl url="http://www.cpan.org/CPAN.html" name="http://www.cpan.org/CPAN.html"> ...
+<P>
+In addition to the standard Red Hat distribution you will require the
+following modules from <htmlurl url="http://www.cpan.org/CPAN.html" name="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.
<P>
<itemize>
</itemize>
<P>
-Copy the CPAN modules listed above to a convenient place on your computer. One good place would be /usr/local/packages, and the instructions which follow will assume that that's where you have put them.
+Copy the CPAN modules listed above to a convenient place on your computer. One good
+place would be /usr/local/packages, and the instructions which follow will assume that
+that's where you have put them.
<P>
Log in as 'root', and make sure you're at '/root' before you continue. Here are exactly the commands you must issue next: -
</verb>
<P>
-Do not fall into the trap of thinking they're all the same, just because they nearly are! Pay particular attention to the instructions of IO, above.
+Do not fall into the trap of thinking they're all the same, just because they
+nearly are! Pay particular attention to the instructions of <em>IO</em>, above.
<sect1>Preparation
on your security requirements you may wish to use an existing user,
however this is your own choice.
-<P>
<tscreen><verb>
# adduser -m sysop
</verb></tscreen>
+<P>
+For SUSE distributions, the command would be ..
+
+<tscreen><verb>
+# useradd -m sysop
+</verb></tscreen>
+
<P>
Now set a password for the user ...
# groupadd -g 251 spider (or another number)
</verb></tscreen>
+<P>
If you do not have the command <em>groupadd</em> available to you simply
add a line in /etc/group by hand.
# vi /etc/group (or your favorite editor)
</verb></tscreen>
+<P>
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
<P>
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 ....
+sysop callsign and other user info to suit your own environment.
+
+<tscreen><verb>
+$mycall = "GB7DJK";
+</verb></tscreen>
+
+<P>
+This is the call sign of your cluster. If you use an SSID then include it here
+also.
+
+<tscreen><verb>
+$myalias = "G1TLH";
+</verb></tscreen>
+
+<P>
+This is the sysop user callsign, normally your own.
+
+<P>
+<bf>PLEASE USE CAPITAL LETTERS FOR CALLSIGNS</bf>
+
+<P>
+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 ....
<tt>
$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.
-<P><bf>PLEASE USE CAPITAL LETTERS FOR CALLSIGNS</bf>
-
<P>
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
$ ./create_sysop.pl
</verb></tscreen>
+<sect1>The client program
+
+<P>
+In earlier versions of Spider, all the processes were Perl scripts. This
+was fine but with a lot of users your computer memory would soon be used up.
+To combat this a new client was written in "C". This client only works for
+<em>incoming</em> connects at the moment. Before you can use it though it
+has to be "made". CD to /spider/src and type <em>make</em>. You
+should see the output on your screen and hopefully now have a small C program
+called <em>client</em>. Leave it in this directory.
+
+
<sect1>Starting up for the first time
<P>
G0VGS de GB7MBC 19-Nov-1999 2150Z >
</verb></tscreen>
+<P>
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 ....
<P>
and both the cluster and the client should return to Linux prompts.
-<sect1>The Client program
-
-<P>
-In earlier versions of Spider, all the processes were Perl scripts. This
-was fine but with a lot of users your computer memory would soon be used up.
-To combat this a new client was written in "C". This client only works for
-<em>incoming</em> connects at the moment. Before you can use it though it
-has to be "made". CD to /spider/src and type <em>make</em>. You
-should see the output on your screen and hopefully now have a small C program
-called <em>client</em>. Leave it in this directory.
-
<sect>Linux quick installation guide
<item>./cluster.pl (sysop)
</itemize>
+<P>
Spider should now be running and you should be able to login using the
client program.
<item>killall -HUP inetd (root)
</itemize>
+<P>
Spider should now be able to accept logins via telnet, netrom and ax25.
<itemize>
default * * * * * * - sysop /spider/src/client client %u ax25
</verb></tscreen>
+<P>
or, if you wish your users to be able to use SSID's on their callsigns ..
<tscreen><verb>
default * * * * * * - sysop /spider/src/client client %s ax25
</verb></tscreen>
+<P>
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 first example and
spdlogin 8000/tcp # spider anonymous login port
</verb></tscreen>
+<P>
Then add a line in /etc/inetd.conf like this ....
<tscreen><verb>
killall -HUP inetd
</verb></tscreen>
-
-<P>Now login as <em>sysop</em> and cd spider/src. You can test that spider
+<P>
+Now login as <em>sysop</em> and cd spider/src. You can test that spider
is accepting telnet logins by issuing the following command ....
<tscreen><verb>
./client login telnet
</verb></tscreen>
+<P>
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 not asked for.
connects to GB7DJK-1 [instead of a script called gb7djk-1]).
</descrip>
-
+<P>
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.
G0VGS de GB7MBC 13-Dec-1998 2043Z >
</verb></tscreen>
+<P>
This will start a connection using the script called <em>gb7djk-1</em>. You can
follow the connection by watching the term or console from where you started
<em>cluster.pl</em>. From version 1.47 onwards, you will need to <tt>set/debug connect</tt> first.
'connect' ''
</verb></tscreen>
+<P>
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 connection. Once connected to
DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
</verb></tscreen>
-
+<P>
The line required for Slackware distributions is slightly different. My thanks to
Aurelio, PA3EZL for this information.
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:-
+what this is, then it isn't for you) or get the latest "official"
+release from:-
-<htmlurl url="http://www.dcc.rsgb.org/WinSpider.zip" name="http://www.dcc.rsgb.org/WinSpider.zip">
+<htmlurl url="http://www.dxcluster.org/download/index.html" name="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):-
<htmlurl url="http://www.dxcluster.org/download/CVSlatest.tgz" name="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
+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.
+
+<p>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.
+
+<p>
+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.
-<bf>NOTE:</bf> 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.
+<p>You will need <htmlurl url="http://www.winzip.com" name="winzip"> to
+manipulate the TGZ files (they are bit like ZIP files) if you are not using CVS.
<sect>Installing the software
<P>
-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:-
<item> $mycall - Should hold the callsign of your DX Cluster
<item> $myname - The SysOp's first name
<item> $myalias - the SysOp's callsign. Cannot be the same as $mycall!
+<item> $myqth - The station's geographical location (QTH).
+<item> $mylatitude - The station latitude in degrees and decimal fractions
+<item> $mylongitude - The station longitude in degrees and decimal fractions
+<item> $mylocator - The Maidenhead (or QRA) locator of the station
</itemize>
-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.
+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 "\$".
+
+
+<sect1>Incoming telnets
+
+<P>
+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:-
+
+<tscreen><verb>
+copy \spider\perl\Listeners.pm \spider\local
+cd \spider\local
+notepad listeners.pm
+</verb></tscreen>
+
+The following lines need attention:-
+
+<tscreen><verb>
+["0.0.0.0", 7300],
+</verb></tscreen>
+
+On my machine, I've simply uncommented the "0.0.0.0" entry by
+removing the '#' from the front of the line.
+
+<bf>You MUST carry out this step if you are
+running on a Windows NT, 2000 or XP based system</bf>
+
+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.
+
+<p>If your machine is connected to the internet <bf>and</bf> 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 <bf>all</bf> IP
+addresses).
<sect1>The AGW packet engine
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:-
<tscreen><verb>
cd \spider\perl
perl winclient.pl
</verb></tscreen>
-If you are rewarded with a display which looks something like:-
+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:-
+
+<tscreen><verb>
+Menu->Start->Run
+telnet localhost 7300
+</verb></tscreen>
+
+On getting the <bf>login:</bf> prompt, enter your sysop callsign (the one you
+put in DXVars.pm as $myalias).
+
+<p>I would recommend <bf>strongly</bf> that you obtain a better telnet
+client than that which comes with windows (I use <htmlurl
+url="http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html"
+name="PuTTY">).
+
+<p>Anyway, if you are rewarded with a display which looks something like:-
<tscreen><verb>
Hello Iain, this is GB7SJP in Amersham, Bucks running DXSpider V1.47
from the version of DXVars.pm that was on the machine when I
started the winclient.pl)
-<sect1>Incoming telnets
-
-<P>
-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:-
-
-<tscreen><verb>
-copy \spider\perl\listeners.pm \spider\local
-cd \spider\local
-notepad listeners.pm
-</verb></tscreen>
-
-The following lines need attention:-
-
-<tscreen><verb>
-["0.0.0.0", 7300],
-</verb></tscreen>
-
-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.
+<p>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 <htmlurl
+url="http://www.qsl.net/wd4ngb/telnet.htm" name="DXTelnet">.
<sect1>Connecting to other clusters
<P>
-If you want to connect this to another cluster, then you'll want
-to negotiate a link with someone. For experimental purposes, I'm
-happy to allow folk to connect to GB7DXA (spud.ath.cx), on the
-understanding that the system may or may not be there and may or
-may not be connected to anything particularly useful at any given
-moment. Contact me by Email if you want me to set up a connection
-for you.
+If you want to connect this to another cluster, then you'll want to
+negotiate a link with someone. For experimental purposes, I'm happy to
+allow folk to connect to GB7DXA (spud.ath.cx), on the understanding
+that the system may or may not be there and may or may not be
+connected to anything particularly useful at any given moment. Contact
+me by <htmlurl url="mailto:g0rdi@blacksheep.org" name="Email"> if you
+want me to set up a connection for you.
<sect>General Information
# check every 10 minutes to see if gb7xxx is connected and if not
# start a connect job going
-0,10,20,30,40,50 * * * * start_connect('gb7xxx') if unless connected('gb7xxx')
+0,10,20,30,40,50 * * * * start_connect('gb7xxx') unless connected('gb7xxx')
</verb></tscreen>
<P>
projects / spider.git / blobdiff