make some documentation changes and fix unset/register
[spider.git] / txt / installation.txt
index 21881dc012336f60206a0b044d289f778fc93bb7..a555718bac3803d3248b10d4768c595a42a39086 100644 (file)
@@ -1,7 +1,7 @@
-  The DXSpider Installation Manual v1.47
+  The DXSpider Installation Manual v1.49
   Iain Philipps, G0RDI (g0rdi@77hz.com) and Ian Maude, G0VGS,
   (ianmaude@btinternet.com)
-  version 1.47
+  December 2001 revision 1.1
 
   A reference for SysOps of the DXSpider DXCluster program.
   ______________________________________________________________________
@@ -9,14 +9,14 @@
   Table of Contents
 
 
-  1. Linux Installation (Original version by Iain Philipps, G0RDI)
+  1. Linux Installation
 
      1.1 Introduction
      1.2 Preparation
      1.3 Installing the software
      1.4 Setting callsigns etc
-     1.5 Starting up for the first time
-     1.6 The Client program
+     1.5 The client program
+     1.6 Starting up for the first time
 
   2. Linux quick installation guide
 
@@ -55,7 +55,7 @@
 
   ______________________________________________________________________
 
-  1.  Linux Installation (Original version by Iain Philipps, G0RDI)
+  1.  Linux Installation
 
   1.1.  Introduction
 
 
 
   In addition to the standard Red Hat distribution you will require the
-  following modules from http://www.cpan.org/CPAN.html ...
+  following modules from http://www.cpan.org/CPAN.html , please note
+  however that with later versions of perl, some of these modules may be
+  included with the distribution.  Get the modules anyway and try to
+  install as below.  If they complain, they are probably already a part
+  of your perl distribution.
 
 
 
-  o  Data-Dumper-2.101.tar.gz
+  o  Data-Dumper-2.10.tar.gz
 
   o  TimeDate-1.10.tar.gz
 
 
   o  Net-Telnet-3.02.tar.gz
 
-  o  Curses-1.05.tar.gz
+  o  Curses-1.06.tar.gz
 
   o  Time-HiRes-01.20.tar.gz
 
 
-  Do get the latest versions of these packages and install them but use
-  the above list as the earliest versions usable.
+  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.
+
+
+  Log in as 'root', and make sure you're at '/root' before you continue.
+  Here are exactly the commands you must issue next: -
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  # 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 ..
+
+
+
+
+  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.
+
 
 
   1.2.  Preparation
   your own choice.
 
 
+       # adduser -m sysop
 
 
-       # adduser -m sysop
 
 
 
+  For SUSE distributions, the command would be ..
 
 
-  Now set a password for the user ...
 
+       # useradd -m sysop
 
 
 
 
 
-  # passwd sysop
-  # New UNIX password:
-  # Retype new UNIX password:
-  passwd: all authentication tokens updated successfully
+  Now set a password for the user ...
+
+
+
+       # passwd sysop
+       # New UNIX password:
+       # Retype new UNIX password:
+       passwd: all authentication tokens updated successfully
 
 
 
 
 
 
+
   If you do not have the command groupadd available to you simply add a
   line in /etc/group by hand.
 
 
 
 
+
   You also need to add some others to the group, including your own
   callsign (this will be used as an alias) and root.  The finished line
   in /etc/group should look something like this
   The next step is to set the permissions on the Spider directory tree
   and files ....
 
-
-
        # chown -R sysop.spider spider
        # find . -type d -exec chmod 2775 {} \;
        # find . -type f -exec chmod 775 {} \;
 
 
 
-
-  # chown root ax25_call netrom_call
-  # chmod 4775 ax25_call netrom_call
+       # chown root ax25_call netrom_call
+       # chmod 4775 ax25_call netrom_call
 
 
 
 
   Using the distributed DXVars.pm as a a template, set your cluster
   callsign, sysop callsign and other user info to suit your own
-  environment. Note that this a perl file which will be parsed and
-  executed as part of the cluster. If you get it wrong then perl will
-  complain when you start the cluster process.  It is important only to
-  alter the text of any section.  Some of the lines look a little odd.
-  Take this line for example ....
+  environment.
 
-  $myemail = "ianmaude\@btinternet.com";
 
 
-  There appears to be an extra slash in there.  However this has to be
-  there for the file to work so leave it in.
+       $mycall = "GB7DJK";
+
+
+
+
+
+  This is the call sign of your cluster.  If you use an SSID then
+  include it here also.
+
+
+
+       $myalias = "G1TLH";
+
+
+
+  This is the sysop user callsign, normally your own.
 
 
   PLEASE USE CAPITAL LETTERS FOR CALLSIGNS
 
 
+  Note that this a perl file which will be parsed and executed as part
+  of the cluster. If you get it wrong then perl will complain when you
+  start the cluster process.  It is important only to alter the text of
+  any section.  Some of the lines look a little odd.  Take this line for
+  example ....
+
+  $myemail = "ianmaude\@btinternet.com";
+
+
+  There appears to be an extra slash in there.  However this has to be
+  there for the file to work so leave it in.
+
+
   DON'T alter any file in /spider/perl, they are overwritten with every
   release. Any files or commands you place in /spider/local or
   /spider/local_cmd will automagically be used in preference to the ones
 
 
 
+       $ ./create_sysop.pl
 
-  $ ./create_sysop.pl
 
 
 
 
+  1.5.  The client program
+
+  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 incoming connects at the moment.  Before you can
+  use it though it has to be "made".  CD to /spider/src and type make.
+  You should see the output on your screen and hopefully now have a
+  small C program called client.  Leave it in this directory.
+
 
-  1.5.  Starting up for the first time
+
+  1.6.  Starting up for the first time
 
   We can now bring spider up for the first time and see if all is well
   or not!  It should look something like this ...
 
 
 
-       $ ./cluster.pl
-       DXSpider DX Cluster Version 1.47
-       Copyright (c) 1998 Dirk Koopman G1TLH
-       loading prefixes ...
-       loading band data ...
-       loading user file system ...
-       starting listener ...
-       reading existing message headers
-       reading cron jobs
-       orft we jolly well go ...
+
+  $ ./cluster.pl
+  DXSpider DX Cluster Version 1.47
+  Copyright (c) 1998 Dirk Koopman G1TLH
+  loading prefixes ...
+  loading band data ...
+  loading user file system ...
+  starting listener ...
+  reading existing message headers
+  reading cron jobs
+  orft we jolly well go ...
 
 
 
 
 
 
+
   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 ....
 
   and both the cluster and the client should return to Linux prompts.
 
-  1.6.  The Client program
-
-  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 incoming connects at the moment.  Before you can
-  use it though it has to be "made".  CD to /spider/src and type make.
-  You should see the output on your screen and hopefully now have a
-  small C program called client.  Leave it in this directory.
-
 
 
   2.  Linux quick installation guide
 
   o  ./cluster.pl (sysop)
 
+
   Spider should now be running and you should be able to login using the
   client program.
 
 
   o  killall -HUP inetd (root)
 
+
   Spider should now be able to accept logins via telnet, netrom and
   ax25.
 
 
 
 
+
   or, if you wish your users to be able to use SSID's on their callsigns
   ..
 
 
 
 
+
   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
 
 
 
+
+
   3.2.  Allowing telnet connects from users
 
 
 
        spdlogin   8000/tcp     # spider anonymous login port
 
-
-
-
   Then add a line in /etc/inetd.conf like this ....
 
 
 
 
 
-
   Now login as sysop and cd spider/src. You can test that spider is
   accepting telnet logins by issuing the following command ....
 
 
 
 
+
   You should get a login prompt and on issuing a callsign, you will be
   given access to the cluster.  Note, you will not get a password login.
   There seems no good reason for a password prompt to be given so it is
        killall -HUP inetd
 
 
-
-
-
   to make the change happen...
 
 
      installation.  If you haven't set any there, then you should not
      touch these values.
 
+
   o  You can connect to a remote AGW engine (ie on some other machine)
      by changing $addr and $port appropriately.
 
 
 
 
-  set/node gb7baa
+       set/node gb7baa
 
 
 
 
 
 
-
   You should get an initialisation string from DXSpider like this ...
 
 
      #  All lines starting with a # are ignored, as are completely blank
         lines.
 
+
      timeout
         timeout followed by a number is the number of seconds to wait
         for a command to complete. If there is no timeout specified in
 
 
 
-
-  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
-  # you can leave this out if you call the script 'gb7dxm'
-  client gb7dxm ax25
+       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
+       # you can leave this out if you call the script 'gb7dxm'
+       client gb7dxm ax25
 
 
 
        client gb7djk telnet
 
 
-
-
-
   Both these examples assume that everything is set up properly at the
   other end.  You will find other examples in the /spider/examples
   directory.
 
 
 
+
   This will start a connection using the script called gb7djk-1.  You
   can follow the connection by watching the term or console from where
   you started cluster.pl.  From version 1.47 onwards, you will need to
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  <- D G1TLH connect gb7djk-1
-  -> D G1TLH connection to GB7DJK-1 started
-  -> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
-  timeout set to 15
-  CONNECT sort: telnet command: dirkl.tobit.co.uk
-  CHAT "login" -> "gb7djk"
-  received "
-  Red Hat Linux release 5.1 (Manhattan)
-  Kernel 2.0.35 on an i586
-  "
-  received "login: "
-  sent "gb7djk"
-  CHAT "word" -> "gb7djk"
-  received "gb7djk"
-  received "Password: "
-  sent "gb7djk"
-  Connected to GB7DJK-1, starting normal protocol
-  <- O GB7DJK-1 telnet
-  -> B GB7DJK-1 0
-  GB7DJK-1 channel func  state 0 -> init
-  <- D GB7DJK-1
-  <- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
-  <- D GB7DJK-1 PC38^GB7DJK-1^~
-  <- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users  Max users 0  Uptime
-  0 00:00^5447^~
-      etc
+       <- D G1TLH connect gb7djk-1
+       -> D G1TLH connection to GB7DJK-1 started
+       -> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
+       timeout set to 15
+       CONNECT sort: telnet command: dirkl.tobit.co.uk
+       CHAT "login" -> "gb7djk"
+       received "
+       Red Hat Linux release 5.1 (Manhattan)
+       Kernel 2.0.35 on an i586
+       "
+       received "login: "
+       sent "gb7djk"
+       CHAT "word" -> "gb7djk"
+       received "gb7djk"
+       received "Password: "
+       sent "gb7djk"
+       Connected to GB7DJK-1, starting normal protocol
+       <- O GB7DJK-1 telnet
+       -> B GB7DJK-1 0
+       GB7DJK-1 channel func  state 0 -> init
+       <- D GB7DJK-1
+       <- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
+       <- D GB7DJK-1 PC38^GB7DJK-1^~
+       <- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users  Max users 0  Uptime
+       0 00:00^5447^~
+           etc
 
 
 
   This means if a node is unreachable, it will continue sending logins
   and logouts to users even though it is not actually connecting.  To
   avoid this use the following line ...
-
-
-
-
-
-
-
-
   In a script, this might look like ...
 
 
 
 
 
+
   So, the first connection is made by Spider.  This is fine as Spider
   uses the Net_Telnet script from within perl.  This actually uses TCP
   rather than TELNET so no negotiation will be done on the first
   automatically.
 
 
+
   This is not only a way to start the cluster automatically, it also
   works as a watchdog, checking the sanity of DXSpider and respawning it
   should it crash for any reason.  Before doing the following, shutdown
   This line works fine for RedHat distributions. It is also fine for
   SuSE up to 7.0.  From Suse 7.1 you need to add runlevels 2 and 5 like
   this ...
+
+
+
        DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
 
 
      download the necessary software bits and bobs directly to it. There
      are other ways, but this is preferable.
 
-
   o  Another cup of good, strong tea
 
   o  If all goes according to plan, about an hour to spare
 
 
 
+
   I'm not going to bother you with exhaustive details of the rest of
   them, but suffice it to say you need to:
 
   because it suits me.
 
 
-
-
-
   4.6.  Getting Spider
 
   Get the current version of the DX Spider distribution. This needs to
 
 
 
-       cd \spider\local
+  cd \spider\local
 
 
 
 
   o  $mycall  - Should hold the callsign of your DX Cluster
 
-
   o  $myname  - The SysOp's first name
 
   o  $myalias - the SysOp's callsign. Cannot be the same as $mycall!
   o  $passwd - password that matches $login
 
 
+
+
   5.2.  Setting up the initial user files
 
   Next you need to create the initial user files, etc. A tool is
 
 
 
-
-  perl cluster.pl
+       perl cluster.pl
 
 
 
 
 
 
-       cd \spider\perl
-       perl winclient.pl
+
+  cd \spider\perl
+  perl winclient.pl
 
 
 
   connected to anything particularly useful at any given moment. Contact
   me by Email if you want me to set up a connection for you.
 
-
   6.  General Information
 
   The following relates to all versions of DXSpider and is not platform
        # 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')
+
+
 
 
 
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-