s DX Spider Installation

Installing DX Spider (on Redhat 5.1)

Iain Phillips G0RDI
Last modified: Tue Sep 18 17:54:45 BST 2001

This HOWTO describes the installation for DX Spider v1.30 on a "vanilla" RedHat 5.1 platform, and assumes that you have started with a clean disk, with nothing other than the standard Red Hat 5.1 distribution. I always select 'everything', and that seems to ensure that nothing is missed out :-) [ more normal people may like to try with less Ed ].

WARNING The perl on the vanilla RedHat 5.2 (perl-5.004m4-1.i386.rpm) is BROKEN, please use the one in the Download section.

The crucial ingredient for all of this is Perl 5.004. Now I know Perl 5.005 is out and this will almost certainly work with it, but RedHat 5.1 comes with 5.004. Be Warned earlier versions of RedHat do not come with 5.004 as standard, you need to upgrade

In addition to the standard Red Hat distribution you will require the following CPAN modules:

IO-1.20.tar.tgz (only on perl 5.00503 and below, do: 'perl -v' to find out what version you have)

The modules above are the current versions found at www.cpan.org in the appropriate directories - you can click on the links (above) to download them - particularly useful if you use the Lynx text HTML browser from your Linux box. You may wish to check for more recent versions of these modules and use the newer ones if they are available.

You'll also need the AX25 utility package. There is much debate about what is "best", what is "better". What works for 5.1 is this: -


This can be found at (among other places) ftp://contrib.redhat.com. Note that no attempt is made within this document to describe the steps necessary to install and commission the AX25 kernel package. It remains the responsibility of the reader to have sufficient knowledge and expertise to make this part of the system operation (and to be satisfied that it is operational) before attempting to install DX Spider. Read the AX25-HOWTO and ask around if you still have trouble after that.

The last "must have" is the DX Spider distribution itself, and this is available via: -

The DX Spider Software

We can now begin:-

  1. Copy the CPAN modules listed above to a convenient place on your computer. For no good reason, I put mine in /usr/local/packages, and the instructions which follow will assume that that's where yours are, too.

    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/MD5-1.7.tar.gz
    # cd MD5-1.7
    # perl Makefile.PL
    # make test
    # make install
    # cd ..
    # 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.08.tar.gz
    # cd TimeDate-1.08
    # 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.05.tar.gz
    # cd Curses-1.05
    # 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.

  2. Create a user to run the cluster under. UNDER NO CIRCUMSTANCES USE ROOT

    Again: DO NOT USE root.

    In the instructions which follow, it is assumed that this user is called 'sysop'. You may call it anything you wish. Depending upon your security requirements, you may choose to use an existing user. This will be your choice, not ours!

    # adduser -m sysop

    Now set a password for the user:-

    # passwd sysop
    # New UNIX password:
    # Retype new UNIX password:
    passwd: all authentication tokens updated successfully

    # 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.

  3. Now unpack the DX Spider distribution, set symbolic links and group permissions like this (assumes that the version we're interested in is 1.9. The distribution tar file may be named slightly differently in your case: -
    # cd ~sysop
    # tar xvfz spider-1.9.tar.gz
    # ln -s ~sysop/spider /spider
    # groupadd -g 251 spider       (or another number)
    # vi /etc/group                (or your favorite editor)

    add 'sysop', your own callsign (in my case 'g0rdi' - which will be used as an alias) and 'root' to the group spider. The result should look something like:-


  4. Next step is to set 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 {} \;

    This last step allows various users of group spider to have write access to all the directories. Not really needed for now but will be useful when web interfaces start to appear.

  5. In later releases there is a client program written in C. You must make this program before you can use it (and you must remember to to remake with every new release).

    To do this you should:-

    # cd /spider/src
    # make

    You can continue to use the perl client (/spider/perl/client.pl, but support of this will gradually whither away.

  6. If you want to be able to allow people or clusters to login via IP then you will need to set up logins for them.

    # useradd -m gb7djk
    # passwd gb7djk
    New UNIX password: 
    Retype new UNIX password: 
    passwd: all authentication tokens updated successfully

    You can then either alter the default .bashrc so that it contains just one line (assuming you use the default bash shell).

    exec /spider/perl/client.pl <callsign> telnet

    Alternatively you can alter the /etc/passwd thus:-

    gb7djk:x:506:506::/home/gb7djk:/usr/bin/perl /spider/perl/client.pl gb7djk telnet
    Don't forget to give them a real password. The telnet argument does two things, it sets the EOL convention to \n rather than AX25's \r and it automatically reduces the privilege of the <callsign> to a 'safe[r]' level.). If the user or other cluster program requires AX25 conventions to operate then you can use ax25 instead.

    Another thing you can do is to get inetd to listen on a specific port and then start the client up directly. To do this, create an entry in /etc/services with a port number > 1000 that isn't used elsewhere eg:-

    gb7djk     8001/tcp 
    gb7tlh     8002/tcp
    Then create some lines in /etc/inetd.conf that look like this:-

    gb7djk  stream tcp   nowait   sysop /usr/sbin/tcpd /spider/src/client gb7djk telnet
    gb7tlh  stream tcp   nowait   sysop /usr/sbin/tcpd /spider/src/client gb7tlh telnet
    Please DON'T run the client as root you will only come to regret it later when the next person finds a security hole in DX Spider (there are bound to be some although I have tried to avoid the obvious ones I could think of).

    The only reason I would use this mechanism is for Internet connections to other or from other clusters. Don't use this for normal users.

    In the example I have used tcpd as the access control mechanism to the port. Don't (I can't be bothered to emphasize it any more) run a system like this without one, you are asking for trouble. In fact I use the TIS Firewall Toolkit myself, you may find this more intuitive to use. The point is that gb7djk would only be coming from one IP address, if it coming from another, it is an imposter!

    You are responsible for arranging and looking after your security - not me.

  7. As mentioned earlier, for AX25 connections you are expected to have the AX25 utilities installed, setup, tested and working. See the AX25-HOWTO for more info on this - it really is beyond the scope of this document DX Spider uses ax25d for incoming connections. You need to have entries like this:-
    NOCALL   * * * * * *  L                                                      
    default  * * * * * *  - sysop /spider/src/client client %u ax25
    NOCALL   * * * * * *  L                                                       
    default  * * * * * *  - sysop /spider/src/client client %u ax25

    where 'ether' and 'bbs' are appropriate KNOWN WORKING axport and nrport names respectively. Obviously you can use different names, callsigns or whatever for your purposes, but it is up to you to get it to work. Note I use BPQ over ethernet which why I have the port names I have.

  8. Find your netrom_call and ax25_call programs (which on my system live in /usr/sbin) and chmod them so that they are SUID root
    # chown root ax25_call netrom_call
    # chmod 4775 ax25_call netrom_call

    This has to be done to allow you to specify the correct callsigns on outgoing connects

  9. Login to your computer as sysop, and create the initial DX Spider parameters necessary to start the cluster for the first time.
    $ startx			(much easier to use X)
    $ cd /spider
    $ mkdir local
    $ mkdir local_cmd
    $ cp perl/DXVars.pm local
    $ cd local
    $ vi DXVars.pm			(or 'joe DXVars.pm' if you're a WordStar fan ;-)

    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.


    DON'T alter the DXVars.pm (or any other 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 whilst the cluster is running!

    $ cd ../perl

    Next, run the following script, which will create the basic user file with you as the sysop.

    $ create_sysop.pl

    Now attempt to startup the cluster program and see whether all the various rivets are flying in approximate formation...

    $ cluster.pl
    DXSpider DX Cluster Version 1.9
    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 ...

  10. now log in again (as 'sysop') or start another rxvt or xterm
    $ client.pl

    at the cluster prompt (which will look something like):-

    G1JIM de GB7JIM 12-Dec-98 1718Z >
    set/node GB7XXX

    (where 'GB7XXX' is a DX cluster which you expect to connect to or from).

    Now shut the cluster down by simply typing 'shutdown' at the prompt.

    The cluster and the client should both go back to prompts

    The callsigns should be the sysop callsign and the cluster callsign as per your modified DXVars.pm. You can check that the cluster connections will work by:-

    $ client.pl gb7xxx      (doesn't have to be uppercase).
    PC38^GB7JIM^~           <- the cluster thinks this is a cluster
    ^C                      <- to get out

  11. Finally try:-
    $ console.pl 

    This is the normal way (as of version 1.30) of running the cluster system as a sysop. It is a simple program client program that allows you to press <up-arrow> <down-arrow> and use all the usual line editting keystrokes that you can use on the unix shell under linux or bash.

    In addition, it will highlight certain type of lines in particular colours and allow you to scroll the top window up and down with the <page-up> and <page-down> keys.

You should now have a basic working system. Best of luck! Can I now draw your attention to the Bug Reporting System.

Can I commend to you the Announcements mailing list to which you may subscribe. This is a low volume mailing list which will send you announcements of new patches and such like things as they arise.

If you like what you see and want to be a part of the ongoing development then subscribe to the support mailing list which will be the focus of any discussion/bug fixing etc.


Copyright © 1998 by Dirk Koopman G1TLH and Iain Phillips G0RDI. All Rights Reserved