mirror of
git://scm.dxcluster.org/scm/spider
synced 2024-09-21 07:47:10 +00:00
1291 lines
41 KiB
Plaintext
1291 lines
41 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
<!-- Title information -->
|
|
|
|
<title>The DXSpider Installation Manual v1.49</title>
|
|
<author>Iain Philipps, G0RDI (g0rdi@77hz.com) and
|
|
Ian Maude, G0VGS, (ianmaude@btinternet.com)</author>
|
|
<date>December 2001 revision 1.1</date>
|
|
|
|
<abstract>
|
|
A reference for SysOps of the DXSpider DXCluster program.
|
|
</abstract>
|
|
|
|
<!-- Table of contents -->
|
|
<toc>
|
|
|
|
<!-- Begin the document -->
|
|
|
|
<sect>Linux Installation
|
|
|
|
<sect1>Introduction
|
|
|
|
<P>
|
|
This section describes the installation of DX Spider v1.47 on a
|
|
<htmlurl url="http://www.redhat.com" name="RedHat"> Linux Distribution.
|
|
Wherever possible I will try to include differences for other distributions.
|
|
I do not intend to try and cover the installation of Linux or the setup
|
|
of the AX25 utilities. If you need help on this then read Iains original
|
|
installation guide that comes with the Spider distribution.
|
|
|
|
<P>
|
|
I am assuming a general knowledge of Linux and its commands. You should
|
|
know how to use <em>tar</em> and how to edit files using your favourite editor.
|
|
|
|
<P>
|
|
The crucial ingredient for all of this is
|
|
<htmlurl url="http://www.perl.org" name="Perl">. Earlier versions of
|
|
Spider required perl 5.004, however it is now <it>STRONGLY</it> recommended
|
|
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"> , 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>
|
|
<item> <htmlurl url="http://www.cpan.org/modules/by-module/Data/Data-Dumper-2.10.tar.gz" name="Data-Dumper-2.10.tar.gz">
|
|
<item> <htmlurl url="http://www.cpan.org/modules/by-module/Date/TimeDate-1.10.tar.gz" name="TimeDate-1.10.tar.gz">
|
|
<item> <htmlurl url="http://www.cpan.org/modules/by-module/IO/IO-1.20.tar.gz" name="IO-1.20.tar.gz (for perl 5.00403 and lower)">
|
|
<item> <htmlurl url="http://www.cpan.org/modules/by-module/Net/Net-Telnet-3.02.tar.gz" name="Net-Telnet-3.02.tar.gz">
|
|
<item> <htmlurl url="http://www.cpan.org/modules/by-module/Curses/Curses-1.06.tar.gz" name="Curses-1.06.tar.gz">
|
|
<item> <htmlurl url="http://www.cpan.org/modules/by-module/Time/Time-HiRes-01.20.tar.gz" name="Time-HiRes-01.20.tar.gz">
|
|
</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.
|
|
|
|
<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>
|
|
# tar xvfz /usr/local/packages/Data-Dumper-2.10.tar.gz
|
|
# cd Data-Dumper-2.10
|
|
# perl Makefile.PL
|
|
# make test
|
|
# make install
|
|
# cd ..
|
|
#
|
|
# tar xvfz /usr/local/packages/TimeDate-1.10.tar.gz
|
|
# cd TimeDate-1.10
|
|
# perl Makefile.PL
|
|
# make test
|
|
# make install
|
|
# cd ..
|
|
#
|
|
# tar xvfz /usr/local/packages/IO-1.20.tar.gz
|
|
# cd IO-1.20
|
|
# perl Makefile.PL
|
|
# make test
|
|
# make install UNINST=1
|
|
# cd ..
|
|
#
|
|
# tar xvfz /usr/local/packages/Net-Telnet-3.02.tar.gz
|
|
# cd Net-Telnet-3.02
|
|
# perl Makefile.PL
|
|
# make test
|
|
# make install
|
|
# cd ..
|
|
#
|
|
# tar xvfz /usr/local/packages/Curses-1.06.tar.gz
|
|
# cd Curses-1.06
|
|
# perl Makefile.PL
|
|
# make test
|
|
# make install
|
|
# cd ..
|
|
#
|
|
# tar xvfz /usr/local/packages/Time-HiRes-01.20.tar.gz
|
|
# cd Time-HiRes-01.20
|
|
# perl Makefile.PL
|
|
# make test
|
|
# make install
|
|
# cd ..
|
|
</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 <em>IO</em>, above.
|
|
|
|
|
|
<sect1>Preparation
|
|
|
|
<P>
|
|
I will assume that you have already downloaded the latest tarball of
|
|
the DXSpider software and are ready to install it. I am assuming version
|
|
1.47 for this section but of course you would use the latest version.
|
|
|
|
<P>
|
|
Login as root and create a user to run the cluster under. <bf><it>UNDER
|
|
NO CIRCUMSTANCES USE ROOT AS THIS USER!</it></bf>. I am going to use
|
|
the name <em>sysop</em>. You can call it anything you wish. Depending
|
|
on your security requirements you may wish to use an existing user,
|
|
however this is your own choice.
|
|
|
|
<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 ...
|
|
|
|
<tscreen><verb>
|
|
# passwd sysop
|
|
# New UNIX password:
|
|
# Retype new UNIX password:
|
|
passwd: all authentication tokens updated successfully
|
|
</verb></tscreen>
|
|
|
|
<sect1>Installing the software
|
|
|
|
<P>
|
|
Now to unpack the DX Spider distribution, set symbolic links and group
|
|
permissions. Copy the tarball to /home/sysop and do the following.
|
|
|
|
<tscreen><verb>
|
|
# cd ~sysop
|
|
# tar xvfz spider-1.47.tar.gz
|
|
# ln -s ~sysop/spider /spider
|
|
# 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.
|
|
|
|
<tscreen><verb>
|
|
# 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
|
|
|
|
<tt>
|
|
spider:x:251:sysop,g0vgs,root
|
|
</tt>
|
|
|
|
<P>
|
|
The next step is to set the permissions on the Spider directory tree and files ....
|
|
|
|
<tscreen><verb>
|
|
# chown -R sysop.spider spider
|
|
# find . -type d -exec chmod 2775 {} \;
|
|
# find . -type f -exec chmod 775 {} \;
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
This last step allows various users of the group <em>spider</em> to have
|
|
write access to all the directories. This is not really needed just yet
|
|
but will be useful when web interfaces start to appear.
|
|
|
|
<P>
|
|
Finally, you need to fix the permissions on the ax25_call and netrom_call
|
|
programs. Check where they are with the <em>locate</em> command and alter
|
|
the permissions with the <em>chmod</em> command like this ..
|
|
|
|
<tscreen><verb>
|
|
# chown root ax25_call netrom_call
|
|
# chmod 4775 ax25_call netrom_call
|
|
</verb></tscreen>
|
|
|
|
<sect1>Setting callsigns etc
|
|
|
|
<P>
|
|
Now login to your machine as the user you created earlier. In my case that
|
|
user is called <em>sysop</em>. Once logged in, issue the following commands ....
|
|
|
|
<tscreen><verb>
|
|
$ cd /spider
|
|
$ mkdir local
|
|
$ mkdir local_cmd
|
|
$ cp perl/DXVars.pm.issue local/DXVars.pm
|
|
$ cd local
|
|
$ vi DXVars.pm (or your favourite editor)
|
|
</verb></tscreen>
|
|
|
|
<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.
|
|
|
|
<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";
|
|
</tt>
|
|
|
|
<P>
|
|
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>
|
|
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 in /spider/perl EVEN
|
|
while the cluster is running!
|
|
|
|
<P>
|
|
Save the new file and change directory to ../perl ....
|
|
|
|
<tscreen><verb>
|
|
$ cd ../perl
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
Now type the following command which creates the basic user file with you as
|
|
the sysop.
|
|
|
|
<tscreen><verb>
|
|
$ ./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>
|
|
We can now bring spider up for the first time and see if all is well or not!
|
|
It should look something like this ...
|
|
|
|
<tscreen><verb>
|
|
$ ./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 ...
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
If all is well then login on another term or console as <em>sysop</em> and
|
|
cd to /spider/src. Now issue the following command ...
|
|
|
|
<tscreen><verb>
|
|
$ ./client
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
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 this case we will assume that this
|
|
was set as GB7MBC. You should therefore see this when you login ....
|
|
|
|
<tscreen><verb>
|
|
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 ....
|
|
|
|
<tscreen><verb>
|
|
shutdown
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
and both the cluster and the client should return to Linux prompts.
|
|
|
|
|
|
<sect>Linux quick installation guide
|
|
|
|
<P>
|
|
This section is designed for experienced Spider sysops who want to install
|
|
Spider from scratch. It is simply a check list of things that need to be
|
|
done without any explanations. The name in brackets at the end of each line
|
|
is the user that should be doing that process.
|
|
|
|
<itemize>
|
|
<item>Login as root
|
|
<item>Get the additional CPAN modules and install them (root)
|
|
<item>Create the "sysop" user and set a password (root)
|
|
<item>Put the Spider tarball in ~sysop and untar it (root)
|
|
<item>ln -s ~sysop/spider /spider (root)
|
|
<item>groupadd -g 251 spider (root)
|
|
<item>Add any more users you need to the group entry in /etc/group (root)
|
|
<item>Set the permissions on the spider tree (root)
|
|
<item>Fix permissions on ax25_call and netrom_call (root)
|
|
<item>Login as the sysop user
|
|
<item>cd to /spider (sysop)
|
|
<item>mkdir local (sysop)
|
|
<item>mkdir local_cmd (sysop)
|
|
<item>cp perl/DXVars.pm.issue local/DXVars.pm (sysop)
|
|
<item>cd to /spider/local and edit DXVars to set your details (sysop)
|
|
<item>cd ../perl (sysop)
|
|
<item>./create_sysop.pl (sysop)
|
|
<item>./cluster.pl (sysop)
|
|
</itemize>
|
|
|
|
<P>
|
|
Spider should now be running and you should be able to login using the
|
|
client program.
|
|
|
|
<itemize>
|
|
<item>Login as root
|
|
<item>Enter the correct line in ax25d.conf (root)
|
|
<item>Enter the correct line in /etc/services (root)
|
|
<item>Enter the correct line in /etc/inetd.conf (root)
|
|
<item>killall -HUP inetd (root)
|
|
</itemize>
|
|
|
|
<P>
|
|
Spider should now be able to accept logins via telnet, netrom and ax25.
|
|
|
|
<itemize>
|
|
<item>Login as sysop
|
|
<item>Start the cluster (sysop)
|
|
<item>set/node and type for links (sysop)
|
|
<item>Write any connect scripts (sysop)
|
|
<item>Edit /spider/crontab as required (sysop)
|
|
<item>Edit any other files as necessary (sysop)
|
|
<item>Set filters, hops and forwarding files (sysop)
|
|
<item>Login as root
|
|
<item>Enter the correct line in /etc/inittab (root)
|
|
</itemize>
|
|
|
|
<sect>Configuration
|
|
|
|
<sect1>Allowing ax25 connects from users
|
|
|
|
<P>
|
|
As stated previously, the aim of this document is not to tell you how to
|
|
configure Linux or the ax25 utilities. However, you do need to add a line
|
|
in your ax25d.conf to allow connections to DXSpider for your users. For
|
|
each interface that you wish to allow connections on, use the following format ...
|
|
|
|
<tscreen><verb>
|
|
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
|
|
then add a specific line for that node like this:
|
|
|
|
<tscreen><verb>
|
|
GB7DJK-2 * * * * * * - sysop /spider/src/client client gb7djk-2 ax25
|
|
default * * * * * * - sysop /spider/src/client client %u ax25
|
|
</verb></tscreen>
|
|
|
|
<sect1>Allowing telnet connects from users
|
|
|
|
<P>
|
|
From version 1.47 there is a new (more efficient) way of doing this
|
|
(see next section) but, if you prefer, the method of doing it described
|
|
here will continue to work just fine.
|
|
|
|
<P>
|
|
Allowing telnet connections is quite simple. Firstly you need to add a line
|
|
in /etc/services to allow connections to a port number, like this ....
|
|
|
|
<tscreen><verb>
|
|
spdlogin 8000/tcp # spider anonymous login port
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
Then add a line in /etc/inetd.conf like this ....
|
|
|
|
<tscreen><verb>
|
|
spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
Once this is done, you need to restart inetd 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
|
|
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.
|
|
|
|
<P>
|
|
Assuming all is well, then try a telnet from your linux console ....
|
|
|
|
<tscreen><verb>
|
|
telnet localhost 8000
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
You should now get the login prompt and be able to login as before.
|
|
|
|
<sect1>Setting up telnet connects (from 1.47 onwards)
|
|
|
|
<P>
|
|
From version 1.47 you can choose to allow the perl cluster.pl program to
|
|
allow connections directly (i.e. not via the <tt>/spider/src/client</tt>
|
|
interface program). If you are using Windows then this is the only method
|
|
available of allowing incoming telnet connections.
|
|
|
|
<P>
|
|
To do this you need first to remove any line that you may previously have set
|
|
up in /etc/inetd.conf. Remember to:-
|
|
|
|
<tscreen><verb>
|
|
killall -HUP inetd
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
to make the change happen...
|
|
|
|
<P>
|
|
Having done that, you need to copy the file
|
|
<em>/spider/perl/Listeners.pm</em> to <em>/spider/local</em> and
|
|
then edit it. You will need to uncomment the line containing &dquot;0.0.0.0&dquot;
|
|
and select the correct port to listen on. So that it looks like this:-
|
|
|
|
<tscreen><verb>
|
|
@listen = (
|
|
["0.0.0.0", 8000],
|
|
);
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
As standard, the listener will listen on all interfaces simultaneously.
|
|
If you require more control than this, you can specify each interface
|
|
individually:-
|
|
|
|
<tscreen><verb>
|
|
@listen = (
|
|
["gb7baa.dxcluster.net", 8000],
|
|
["44.131.16.2", 6300],
|
|
);
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
This will only be successful if the IP addresses on each interface are static.
|
|
If you are using some kind of dynamic IP addressing then the 'default' method
|
|
is the only one that will work.
|
|
|
|
<P>
|
|
Restart the cluster.pl program to enable the listener.
|
|
|
|
<P>
|
|
One important difference with the internal listener is that no echoing
|
|
is done by the cluster program. Users will need to set 'local-echo' on in
|
|
their telnet clients if it isn't set automatically (as per the standards).
|
|
Needless to say this will probably only apply to Windows users.
|
|
|
|
<sect1>Setting up for AGW Engine (1.47 onwards)
|
|
|
|
<P>
|
|
AGW Engine is a Windows based ax25 stack. You can connect to an AGW engine
|
|
from Linux as well as Windows based machines.
|
|
|
|
<P>
|
|
In order to enable access to an AGW Engine you need to copy
|
|
<em>/spider/perl/AGWConnect.pm</em> to <em>/spider/local</em> and edit it.
|
|
Specifically you must:-
|
|
|
|
<itemize>
|
|
<item> set <tt>$enable</tt> to 1.
|
|
<item> set <tt>$login</tt> and <tt>$passwd</tt> to the values set up in your AGW installation.
|
|
If you haven't set any there, then you should not touch these values.
|
|
<item> You can connect to a remote AGW engine (ie on some other machine) by changing <tt>$addr</tt>
|
|
and <tt>$port</tt> appropriately.
|
|
<item> Restart the cluster.pl program
|
|
</itemize>
|
|
|
|
|
|
<sect1>Setting up node connects
|
|
|
|
<P>
|
|
In order to allow cluster node connections, spider needs to know that the
|
|
connecting callsign is a cluster node. This is the case whether the connect
|
|
is incoming or outgoing. In spider this is a simple task and can be done in
|
|
runtime.
|
|
|
|
<P>
|
|
Later versions of Spider can distinguish different software and treat them
|
|
differently. For example, the WCY beacon cannot be handles by AK1A type
|
|
nodes as AK1A does not know what to do with PC73. There are 4 different
|
|
types of node at present and although they may not have any major
|
|
differences at the moment, it allows for compatibility. The 4 types are ...
|
|
|
|
<tscreen><verb>
|
|
set/node (AK1A type)
|
|
set/spider
|
|
set/dxnet
|
|
set/clx
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
For now, we will assume that the cluster we are going to connect to is an
|
|
AK1A type node.
|
|
|
|
<P>
|
|
Start up the cluster as you did before and login as the sysop with client.
|
|
The cluster node I am wanting to make a connection to is GB7BAA but you would
|
|
obviously use whatever callsign you required. At the prompt type ...
|
|
|
|
<tscreen><verb>
|
|
set/node gb7baa
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
The case does not matter as long as you have a version of DXSpider later than
|
|
1.33. Earlier versions required the callsign to be in upper case.
|
|
|
|
<P>
|
|
That is now set, it is as simple as that. To prove it, login on yet another
|
|
console as sysop, cd to spider/src and issue the command ...
|
|
|
|
<tscreen><verb>
|
|
./client gb7baa (using the callsign you set as a node)
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
You should get an initialisation string from DXSpider like this ...
|
|
|
|
<tscreen><verb>
|
|
./client gb7baa
|
|
PC38^GB7MBC^~
|
|
</verb></tscreen>
|
|
|
|
If the callsign you just set up as a cluster node is for an incoming connect,
|
|
this is all that needs to be done. If the connection is to be outgoing then
|
|
a connection script needs to be written.
|
|
|
|
<P>
|
|
Sometimes you make a mistake... Honest, it does happen. If you want to make a node
|
|
back to being a normal user, regardless
|
|
of what type it is, do:
|
|
|
|
<tscreen><verb>
|
|
unset/node gb7baa
|
|
</verb></tscreen>
|
|
|
|
<sect1>Connection scripts
|
|
|
|
<P>
|
|
Because DXSpider operates under Linux, connections can be made using just about
|
|
any protocol; AX25, NETRom, tcp/ip, ROSE etc are all possible examples.
|
|
Connect scripts live in the /spider/connect directory and are simple ascii files.
|
|
Writing a script for connections is therefore relatively simple.
|
|
|
|
<P>
|
|
The connect scripts consist of lines which start with the following keywords
|
|
or symbols:-
|
|
|
|
<descrip>
|
|
|
|
<tag/#/All lines starting with a <tt>#</tt> are ignored, as are completely
|
|
blank lines.
|
|
|
|
<tag/timeout/<tt>timeout</tt> followed by a number is the number of seconds to wait for a
|
|
command to complete. If there is no timeout specified in the script
|
|
then the default is 60 seconds.
|
|
|
|
<tag/abort/ <tt>abort</tt> is a regular expression containing one or more strings to look
|
|
for to abort a connection. This is a perl regular expression and is
|
|
executed ignoring case.
|
|
|
|
<tag/connect/<tt>connect</tt> followed by ax25, agw (for Windows users) or telnet and some type dependent
|
|
information. In the case of a telnet connection, there can be up to
|
|
two parameters.
|
|
The first is the ip address or hostname of the computer you wish to
|
|
connect to and the second is the port number you want to use (this
|
|
can be left out if it is a normal telnet session).
|
|
In the case of an ax25 session then this would normally be a call to
|
|
ax25_call or netrom_call as in the example above. It is your
|
|
responsibility to get your node and other ax25 parameters to work
|
|
before going down this route!
|
|
|
|
<tag/'/<tt>'</tt> is the delimiting character for a word or phrase of an expect/send
|
|
line in a chat type script. The words/phrases normally come in pairs,
|
|
either can be empty. Each line reads input from the connection until
|
|
it sees the string (or perl regular expression) contained in the
|
|
left hand string. If the left hand string is empty then it doesn't
|
|
read or wait for anything. The comparison is done ignoring case.
|
|
When the left hand string has found what it is looking for (if it is)
|
|
then the right hand string is sent to the connection.
|
|
This process is repeated for every line of chat script.
|
|
|
|
<tag/client/<tt>client</tt> starts the connection, put the arguments you would want here
|
|
if you were starting the client program manually. You only need this
|
|
if the script has a different name to the callsign you are trying to
|
|
connect to (i.e. you have a script called other which actually
|
|
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.
|
|
|
|
<tscreen><verb>
|
|
timeout 60
|
|
abort (Busy|Sorry|Fail)
|
|
# don't forget to chmod 4775 netrom_call!
|
|
connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh
|
|
'Connect' ''
|
|
'Connect' 'c np7'
|
|
'Connect' 'c gb7dxm'
|
|
# you can leave this out if you call the script 'gb7dxm'
|
|
client gb7dxm ax25
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
|
|
<tscreen><verb>
|
|
timeout 60
|
|
abort (Busy|Sorry|Fail)
|
|
# this does exactly the same as the previous example
|
|
# the '1' is the AGW port number to connect thru for g1tlh
|
|
connect agw 1 g1tlh
|
|
'Connect' ''
|
|
'Connect' 'c np7'
|
|
'Connect' 'c gb7dxm'
|
|
# you can leave this out if you call the script 'gb7dxm'
|
|
client gb7dxm ax25
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
|
|
<tscreen><verb>
|
|
timeout 15
|
|
connect telnet dirkl.tobit.co.uk
|
|
'login' 'gb7djk'
|
|
'word' 'gb7djk'
|
|
# tell GB7DJK-1 that it is connected to GB7DJK
|
|
# you can leave this out if you call this script 'gb7djk'
|
|
client gb7djk telnet
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
Both these examples assume that everything is set up properly at the other end.
|
|
You will find other examples in the /spider/examples directory.
|
|
|
|
<sect1>Starting the connection
|
|
|
|
<P>
|
|
You start the connection, from within a sysop enabled cluster login, by typing
|
|
in the word <em>connect</em> followed by a script name like this ....
|
|
|
|
<tscreen><verb>
|
|
G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
|
|
connection to GB7DJK-1 started
|
|
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.
|
|
You should see something like this ...
|
|
|
|
<tscreen><verb>
|
|
<- 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
|
|
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
With later versions of Spider there is a set/login command for users. This
|
|
tells them when a user or node logs in or out. If you do not add a line to
|
|
your scripts after the final line (or before the client line which should always
|
|
be last if needed) then the login/logout information will be sent to users
|
|
<it>before</it> the login actually completes. 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 ...
|
|
|
|
<tscreen><verb>
|
|
'connect' ''
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
In a script, this might look like ...
|
|
|
|
<tscreen><verb>
|
|
timeout 35
|
|
abort (Busy|Sorry|Fail)
|
|
connect telnet mary 3000
|
|
'ogin:' 'gb7mbc'
|
|
'>' 'telnet 44.131.93.96 7305'
|
|
'connect' ''
|
|
</verb></tscreen>
|
|
|
|
<sect1>Telnet echo
|
|
|
|
<P>
|
|
Cluster links in particular suffer greatly from the presence of telnet echo.
|
|
This is caused by the telnet negotiation itself and can create at worst severe
|
|
loops. At best it creates unnecessary bandwidth and large logfiles! There are
|
|
things that can be done to limit this problem but will not always work dependent
|
|
on the route taken to connect.
|
|
|
|
<P>
|
|
Telnet echo itself should only be a problem if the connection is being made to
|
|
the telnet port (23). This port uses special rules that include echo negotiation.
|
|
If the connection is to a different port, such as 7300, this negotiation does
|
|
not happen and therefore no echo should be present.
|
|
|
|
<P>
|
|
Sometimes it is not possible to make a direct connection to another node and this
|
|
can cause problems. There is a way of trying to suppress the telnet echo but
|
|
this will not always work, unfortunately it is difficult to be more specific.
|
|
Here is an example of what I mean ...
|
|
|
|
<tscreen><verb>
|
|
timeout 35
|
|
abort (Busy|Sorry|Fail)
|
|
connect telnet mary.lancs.ac.uk
|
|
'ogin:' 'gb7mbc'
|
|
'word:' 'mypasswd'
|
|
'\$' 'stty -echo raw'
|
|
'\$' 'telnet 44.131.93.96'
|
|
'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
|
|
mary.lancs.ac.uk, the command is sent to suppress echo. Now a telnet is made
|
|
to a cluster node that is accepting connections on port 23. The problem with
|
|
this link is that the negotiation is made by the remote machine, therefore you
|
|
have no control over it. The chances are that this link will create echo and
|
|
there will be no way you can stop it.
|
|
|
|
|
|
<sect1>Autostarting the cluster
|
|
|
|
<P>
|
|
Ok, you should now have DXSpider running nicely and allowing connects by cluster
|
|
nodes or users. However, it has to be shutdown and restarted manually. It
|
|
would be much easier to have it start automatically.
|
|
|
|
<P>
|
|
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 the cluster as you did earlier.
|
|
|
|
<P>
|
|
Login as root and bring up the /etc/inittab file in your favourite editor. Add
|
|
the following lines to the file near the end ...
|
|
|
|
<tscreen><verb>
|
|
##Start DXSpider on bootup and respawn it should it crash
|
|
DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
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 ...
|
|
|
|
<tscreen><verb>
|
|
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.
|
|
|
|
<tscreen><verb>
|
|
DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart
|
|
it should it crash for any reason.
|
|
|
|
<P>
|
|
As root type the command <em>telinit q</em>. DXSpider should start up
|
|
immediately. You will see the output on tty7 and if you login as <em>sysop</em>
|
|
you should find everything running nicely.
|
|
|
|
<sect>Microsoft Windows Installation
|
|
|
|
<sect1>Introduction
|
|
|
|
<P>
|
|
<bf>IMPORTANT:</bf>
|
|
|
|
What you'll be left with once you've followed these instructions
|
|
is (hopefully) a working DX Spider v1.47 system that is capable
|
|
of accepting or originating "internet" connections, plus inbound
|
|
AX.25 and TCP/IP radio connections. If the absence of outbound
|
|
radio connections is a serious limitation for you, it would be
|
|
better for you to wait a couple more weeks until this support has
|
|
been added.
|
|
|
|
On the other hand, you may have an enquiring mind, or better yet,
|
|
may be looking for a useful way of connecting your current
|
|
(perhaps) AK1A cluster "to the internet" via some networking
|
|
mechanism (BPQEther, etc) or other. I won't be producing
|
|
instructions for the latter case, because I don't have an AK1A to
|
|
play with. But someone might ...
|
|
|
|
Whatever, this document is intended to get you started with DX
|
|
Spider in a Microsoft Windows ™ environment. It's not
|
|
intended to teach you anything other than how to perform a
|
|
minimum configuration of a DX Spider installation and have it
|
|
able to connect across "the internet" to other DX Clusters, while
|
|
accepting inbound TELNET and radio connections.
|
|
|
|
<sect1>The requirements
|
|
|
|
<P>
|
|
The very first things you're going to need are (in order of
|
|
importance):-
|
|
|
|
<itemize>
|
|
<item>A cup of good, strong tea
|
|
<item>A supported Windows platform with an internet connection so you can
|
|
download the necessary software bits and bobs directly to it. There are other ways, but this is preferable.
|
|
<item>Another cup of good, strong tea
|
|
<item>If all goes according to plan, about an hour to spare
|
|
<item>Plenty of good, strong tea
|
|
</itemize>
|
|
|
|
<sect1>The system
|
|
|
|
<P>
|
|
The platform I used to generate these instructions was a
|
|
"vanilla" Microsoft Windows Me 4.90.3000 system, with a 700MHz
|
|
AMD Athlon processor and 96 Mb memory. I've also personally
|
|
verified that it runs on my laptop (Pentium 266MHz, 32 Mb memory,
|
|
Windows 98 SE v4.10.2222 A) and a computer that I assembled from
|
|
a random pile of junk (AMD K6-2 333MHz, 64 Mb memory, Windows 98
|
|
v4.10.1998). As a result, I have reason to believe that what I'm
|
|
about to describe will perform equally on any 32-bit MS Windows
|
|
environment with 32 Mb of memory.
|
|
|
|
Because of the changes that have recently been made to the core
|
|
"cluster.pl" module and the introduction of a very lightweight
|
|
"winclient.pl", I have a sneaking suspicion that this will now
|
|
run on any platform that has reasonably complete support for
|
|
Perl. Is there someone out there with both an enquiring mind and
|
|
(say) a Macintosh, for instance?
|
|
|
|
Please bear in mind, though, that my instructions relate solely
|
|
to how to get this going under a Microsoft Windows environment,
|
|
and I have zero intention of trying to make them say otherwise.
|
|
|
|
<sect1>Perl
|
|
|
|
<P>
|
|
Install your chosen Perl environment. Unless you have a very good
|
|
reason for not doing so, I strongly suggest that you use
|
|
ActivePerl v5.6. For my testing & development, I used build 623.
|
|
You can get this from:- <htmlurl
|
|
url="http://www.activestate.com/Products/ActivePerl/Download.html"
|
|
name="http://www.activestate.com/Products/ActivePerl/Download.html">
|
|
|
|
You will need to choose either the MSI or the AS package. My
|
|
recommendation is that you choose the MSI package and deal with
|
|
the consequences if your system isn't equipped with support for
|
|
the latest MS Installer; you'll be better off in the long run.
|
|
The build 623 download is 7,460 KB, so now is a really good time
|
|
to have some tea if you're on a slow dial-up connection.
|
|
|
|
During installation, please ensure that you do choose the options
|
|
to "Add Perl to the PATH environment variable" and "Create Perl
|
|
file extension association"; it will make your life so much
|
|
easier. Once the installation is finished, be sure to reboot your
|
|
PC. You probably won't be told anywhere else that this needs to
|
|
be done now, but it does. Really.
|
|
|
|
Once you've rebooted, open a "DOS box" (Start > Run > command
|
|
might do it, if you can't find it elsewhere) and from wherever it
|
|
lands, type PERL -v <ENTER> (it's better if that's a lower-case
|
|
'v', because an upper-case 'V' means something else. You should
|
|
be rewarded with some interesting information about your Perl
|
|
installation. If you're not, you must go back to the beginning
|
|
and discover what went wrong and fix it. It's pointless to
|
|
proceed unless this simple check is passed. Assuming it did work,
|
|
you may now move on.
|
|
|
|
<sect1>Additional packages
|
|
|
|
<P>
|
|
Some extensions ("packages") need to be added to the base Perl
|
|
distribution, and we'll do this next. If you're using the Perl I
|
|
recommended, and don't know any better for yourself, then just
|
|
blindly following these instructions will work just fine. If that
|
|
didn't describe you, then you're on your own.
|
|
|
|
Visit the following URL:
|
|
|
|
<htmlurl url="http://www.activestate.com/PPMPackages/zips/6xx-builds-only/"
|
|
name="http://www.activestate.com/PPMPackages/zips/6xx-builds-only/">
|
|
|
|
and download the following files:-
|
|
|
|
<tscreen><verb>
|
|
Data-Dumper.zip
|
|
Net-Telnet.zip
|
|
TimeDate.zip
|
|
Time-HiRes.zip
|
|
DB_File.zip
|
|
</verb></tscreen>
|
|
|
|
Make yourself a convenient directory to unpack all of these zip
|
|
files into (I put mine in "D:\ppm>") and do the following (the
|
|
bits you type in are blue ). Note that where these files land
|
|
will be directly related to where you chose to install your
|
|
ActivePerl (mine, as you can probably guess from what follows,
|
|
went into "D:\Perl"):-
|
|
|
|
<tscreen><verb>
|
|
D:\ppm>ppm install Data-Dumper.ppd
|
|
Installing package 'Data-Dumper.ppd'
|
|
Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.bs
|
|
Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.dll
|
|
Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.exp
|
|
Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.lib
|
|
Installing D:\Perl\html\site\lib\auto\Data\Dumper\Dumper.html
|
|
Installing D:\Perl\site\lib\Data\Dumper\Dumper.pm
|
|
Writing D:\Perl\site\lib\auto\Data\Dumper\Dumper.packlist
|
|
D:\ppm>
|
|
</verb></tscreen>
|
|
|
|
I'm not going to bother you with exhaustive details of the rest
|
|
of them, but suffice it to say you need to:
|
|
|
|
<tscreen><verb>
|
|
ppm install DB_File.ppd
|
|
ppm install Net-Telnet.ppd
|
|
ppm install TimeDate.ppd
|
|
ppm install Time-HiRes.ppd
|
|
</verb></tscreen>
|
|
|
|
If all that seemed to work OK, time to move along. Before anyone
|
|
who is familiar with PPM tells me that we didn't need to download
|
|
and keep those files locally, I knew that. I also knew that PPM
|
|
is sometimes awkward to configure via firewalls, and that
|
|
sometimes the repositories don't always work the way we'd hope. I
|
|
do it that way because it suits me.
|
|
|
|
<sect1>Getting Spider
|
|
|
|
<P>
|
|
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:-
|
|
|
|
<htmlurl url="http://www.dcc.rsgb.org/WinSpider.zip" name="http://www.dcc.rsgb.org/WinSpider.zip">
|
|
|
|
or if you want the lastest 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
|
|
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.
|
|
|
|
<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.
|
|
|
|
Now create your own local copy of the DXVars.pm file by:-
|
|
|
|
<tscreen><verb>
|
|
copy c:\spider\perl\DXVars.pm.issue
|
|
c:\spider\local\DXVars.pm
|
|
</verb></tscreen>
|
|
|
|
Now you'll need to edit this file using a text editor. If nothing
|
|
else, you can simply
|
|
|
|
<tscreen><verb>
|
|
cd \spider\local
|
|
</verb></tscreen>
|
|
|
|
and then
|
|
|
|
<tscreen><verb>
|
|
notepad DXVars.pm
|
|
</verb></tscreen>
|
|
|
|
to bring up an editor window containing the file. As an absolute
|
|
minimum you must adjust the following items in DXVars.pm:-
|
|
|
|
<itemize>
|
|
<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!
|
|
</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.
|
|
|
|
<sect1>The AGW packet engine
|
|
|
|
<P>
|
|
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 local copy of AGWConnect.pm by:-
|
|
|
|
<tscreen><verb>
|
|
copy c:\spider\perl\AGWConnect.pm
|
|
c:\spider\local\AGWConnect.pm
|
|
</verb></tscreen>
|
|
|
|
and then
|
|
|
|
<tscreen><verb>
|
|
notepad AGWConnect.pm
|
|
</verb></tscreen>
|
|
|
|
to bring up an editor window containing the file. You must
|
|
consider adjusting the following items in AGWConnect.pm:-
|
|
|
|
<itemize>
|
|
<item>$enable - set to '1' to enable AGWPE interface
|
|
<item>$login - the login ID you chose when you set up the SV2AGW security :-)
|
|
<item>$passwd - password that matches $login
|
|
</itemize>
|
|
|
|
<sect1>Setting up the initial user files
|
|
|
|
<P>
|
|
Next you need to create the initial user files, etc. A tool is
|
|
supplied which will do this for you. To run the tool:-
|
|
|
|
<tscreen><verb>
|
|
cd \spider\perl
|
|
perl create_sysop.pl
|
|
</verb></tscreen>
|
|
|
|
If all goes according to plan, you will see no output from this
|
|
program, and after a brief wait, your DOS prompt will be
|
|
returned.
|
|
|
|
Depending on how brave you are, you might now care to try the
|
|
following:-
|
|
|
|
<tscreen><verb>
|
|
perl cluster.pl
|
|
</verb></tscreen>
|
|
|
|
If you did everything you were told, your DOS window will now
|
|
hold a display which looks something like:-
|
|
|
|
<tscreen><verb>
|
|
DXSpider DX Cluster Version 1.47
|
|
Copyright (c) 1998-2001 Dirk Koopman G1TLH
|
|
loading prefixes ...
|
|
loading band data ...
|
|
loading user file system ...
|
|
starting listeners ...
|
|
Internal port: localhost 27754
|
|
load badwords: Ok
|
|
reading in duplicate spot and WWV info ...
|
|
reading existing message headers ...
|
|
load badmsg: Ok
|
|
load forward: Ok
|
|
load swop: Ok
|
|
@msg = 0 before delete
|
|
@msg = 0 after delete
|
|
reading cron jobs ...v cron: reading /spider/cmd/crontab
|
|
cron: adding 1 0 * * 0
|
|
DXUser::export("$main::data/user_asc")
|
|
reading database descriptors ...
|
|
doing local initialisation ...
|
|
orft we jolly well go ...
|
|
queue msg (0)
|
|
</verb></tscreen>
|
|
|
|
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:-
|
|
|
|
<tscreen><verb>
|
|
cd \spider\perl
|
|
perl winclient.pl
|
|
</verb></tscreen>
|
|
|
|
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
|
|
Cluster: 1 nodes, 1 local / 1 total users Max users 2 Uptime 0 00:00
|
|
M0ADI de GB7SJP 4-Mar-2001 1511Z >
|
|
</verb></tscreen>
|
|
|
|
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)
|
|
|
|
<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.
|
|
|
|
<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.
|
|
|
|
<sect>General Information
|
|
|
|
<P>
|
|
The following relates to all versions of DXSpider and is not platform related.
|
|
|
|
<sect1>The crontab file
|
|
|
|
<P>
|
|
Login as <em>sysop</em> and create a file in /spider/local_cmd called crontab.
|
|
Edit it with your favourite editor and add a line like this (I have included
|
|
a comment)
|
|
|
|
<tscreen><verb>
|
|
# 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') unless connected('gb7xxx')
|
|
</verb></tscreen>
|
|
|
|
<P>
|
|
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 not,
|
|
then a connect attempt will be started.
|
|
|
|
<P>
|
|
There are probably lots of other things you could use this crontab file for.
|
|
If you want to know more about it, look at the
|
|
<htmlurl url="http://www.dxcluster.org/cron.html" name="DXSpider"> website
|
|
at the cron page where it is explained more fully.
|
|
|
|
</article>
|