--- /dev/null
+<!doctype linuxdoc system>
+
+<article>
+
+<!-- Title information -->
+
+<title>The DXSpider Installation Manual v1.47</title>
+<author>Iain Philipps, G0RDI (g0rdi@77hz.com) and
+Ian Maude, G0VGS, (ianmaude@btinternet.com)</author>
+<date>Version 1.47, April 2001 revision 1.0</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"> ...
+
+<P>
+<itemize>
+<item> Data-Dumper-2.101.tar.gz
+<item> TimeDate-1.10.tar.gz
+<item> IO-1.20.tar.gz (for perl 5.00403 and lower)
+<item> Net-Telnet-3.02.tar.gz
+<item> Curses-1.05.tar.gz
+<item> Time-HiRes-01.20.tar.gz
+</itemize>
+
+<P>
+<em>Do</em> get the latest versions of these packages and install them
+but use the above list as the earliest versions usable.
+
+<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.
+
+<P>
+<tscreen><verb>
+# adduser -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>
+
+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>
+
+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. 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><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
+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>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>
+
+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.
+
+<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
+
+<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>
+
+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>
+
+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>
+
+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>
+
+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>
+
+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>
+
+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>
+
+
+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>
+
+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>
+
+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>
+
+
+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') if 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>
projects / spider.git / commitdiff