X-Git-Url: http://dxcluster.net/gitweb/gitweb.cgi?a=blobdiff_plain;f=sgml%2Finstallation.sgml;fp=sgml%2Finstallation.sgml;h=0000000000000000000000000000000000000000;hb=3d66b51182cb1939154d96def02efb45784958c0;hp=c0fc5edb7f0b75225ceaf16a9ec1bd45ae0ef8a8;hpb=bccf827cfc80f9871efc8a25f9bb69f99c771d77;p=spider.git diff --git a/sgml/installation.sgml b/sgml/installation.sgml deleted file mode 100644 index c0fc5edb..00000000 --- a/sgml/installation.sgml +++ /dev/null @@ -1,1843 +0,0 @@ - - -
- - - -The DXSpider Installation Manual v1.50 -Iain Philipps, G0RDI (g0rdi@77hz.com), -Ian Maude, G0VGS, (g0vgs@gb7mbc.net) and Charlie -Carroll, K1XX, (k1xx@ptcnh.net) -February 2003 revision 0.6 - - -A reference for SysOps of the DXSpider DXCluster program. - - - - - - - -Linux Installation - -Introduction - -

-This section describes the installation of DX Spider v1.50 on a - Linux Distribution. -Wherever possible I will try to include differences for other distributions. - -

-I am assuming a general knowledge of Linux and its commands. You should -know how to use tar and how to edit files using your favourite editor. - -

-The crucial ingredient for all of this is -. Earlier versions of -Spider required perl 5.004, however it is now STRONGLY recommended -that you use at least version 5.005_03 as this is the version being used -in the development of Spider. - -

-In addition to the standard Red Hat distribution you will require the -following modules from , 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. - -

- - - - - - - - - - -

-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.101.tar.gz -# cd Data-Dumper-2.101 -# 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.03.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 .. -# -# tar xvfz /usr/local/packages/Digest-SHA1-2.01.tar.gz -# cd Digest-SHA1-2.01 -# 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. - - -Preparation - -

-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.50 for this section but of course you would use the latest version. - -

-Login as root and create a user to run the cluster under. UNDER -NO CIRCUMSTANCES USE ROOT AS THIS USER!. I am going to use -the name sysop. 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. - - -# adduser -m sysop - - -

-For SuSE distributions, the command would be .. - - -# useradd -m sysop - - -

-Now set a password for the user ... - - -# passwd sysop -# New UNIX password: -# Retype new UNIX password: -passwd: all authentication tokens updated successfully - - -Installing the software - -

-Now to unpack the DX Spider distribution, set symbolic links and group -permissions. Copy the tarball to /home/sysop and do the following. - - -# cd ~sysop -# tar xvfz spider-1.50.tar.gz -# ln -s ~sysop/spider /spider -# groupadd -g 251 spider (or another number) - - -

-If you do not have the command groupadd available to you simply -add a line in /etc/group by hand. - - -# vi /etc/group (or your favorite editor) - - -

-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 - - -spider:x:251:sysop,g0vgs,root - - -

-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 {} \; - - -

-This last step allows various users of the group spider 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. - -

-Finally, you need to fix the permissions on the ax25_call and netrom_call -programs. Check where they are with the locate command and alter -the permissions with the chmod command like this .. - - -# chown root ax25_call netrom_call -# chmod 4775 ax25_call netrom_call - - -Setting callsigns etc - -

-Now login to your machine as the user you created earlier. In my case that -user is called sysop. Once logged in, issue the following commands .... - - -$ cd /spider -$ mkdir local -$ mkdir local_cmd -$ cp perl/DXVars.pm.issue local/DXVars.pm -$ cd local -$ vi DXVars.pm (or your favourite editor) - - -

-Using the distributed DXVars.pm as a a template, set your cluster callsign, -sysop callsign and other user info to suit your own environment. - - -$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 in /spider/perl EVEN -while the cluster is running! - -

-Save the new file and change directory to ../perl .... - - -$ cd ../perl - - -

-Now type the following command which creates the basic user file with you as -the sysop. - - -$ ./create_sysop.pl - - -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. - - -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.50 -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 all is well then login on another term or console as sysop and -cd to /spider/src. Now issue the following command ... - - -$ ./client - - -

-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 .... - - -G0VGS de GB7MBC 19-Nov-1999 2150Z > - - -

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

-and both the cluster and the client should return to Linux prompts. - - -Linux quick installation guide - -

-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. - - -Login as root -Get the additional CPAN modules and install them (root) -Create the "sysop" user and set a password (root) -Put the Spider tarball in ~sysop and untar it (root) -ln -s ~sysop/spider /spider (root) -groupadd -g 251 spider (root) -Add any more users you need to the group entry in /etc/group (root) -Set the permissions on the spider tree (root) -Fix permissions on ax25_call and netrom_call (root) -Login as the sysop user -cd to /spider (sysop) -mkdir local (sysop) -mkdir local_cmd (sysop) -cp perl/DXVars.pm.issue local/DXVars.pm (sysop) -cd to /spider/local and edit DXVars to set your details (sysop) -cd ../perl (sysop) -./create_sysop.pl (sysop) -./cluster.pl (sysop) - - -

-Spider should now be running and you should be able to login using the -client program. - - -Login as root -Enter the correct line in ax25d.conf (root) -Enter the correct line in /etc/services (root) -Enter the correct line in /etc/inetd.conf (root) -killall -HUP inetd (root) - - -

-Spider should now be able to accept logins via telnet, netrom and ax25. - - -Login as sysop -Start the cluster (sysop) -set/node and type for links (sysop) -Write any connect scripts (sysop) -Edit /spider/crontab as required (sysop) -Edit any other files as necessary (sysop) -Set filters, hops and forwarding files (sysop) -Login as root -Enter the correct line in /etc/inittab (root) - - -Setting up the AX25 Utilities - -

-The aim of this section is not to fully cover the installation -and configuration of all the possible ax25 modules. I will -attempt to cover a simple installation and configure 2 serial -ports as if they had TNC's on them. I will also show what -additional configuration the DXSpider program requires. - -

-Please bear in mind that I am basing this section on a RedHat -7.1 distribution, if you are using SuSe or any other distibution -then your mileage may vary. I will be happy to make any changes -and additions if you email me any errors or distribution specific -requirements. - -

-You would probably benefit from reading the which is much more -comprehensive and an interesting configuration program is also available -called which -may help you to configure things. - -

-The following files are extracts from the working files at GB7MBC and -are in daily use. However, there are many ways that you can configure the -ax25 utils, this is just the one I use, it does not mean it is necessarily -the best or for that matter, the right way! - -Getting Started - -

-There are 2 things you need to do initially. You need to get the -3 files required for the ax25 installation and you need to make -some changes to the kernel configuration. - -

-The first thing is to get the versions of the ax25 utils that match -your kernel. You may also wish to get a node package of some kind. -There are 2 main node packages in use of which I shall keep to the -original by Tomi Manninen, OH2BNS as this is included in the ax25 -rpms as standard. The other is by IZ5AWZ. - -

-NB: The AX25 stuff in 2.4 kernels appears to have been broken until 2.4.18. I -strongly suggest you get at least this kernel. - -

-For 2.4 kernels you need these files... - -

- - - - - - -The kernel - -

-First you need to add Amateur Radio Support to your kernel. This is -a main menu item and should be easily found. Within this header you -will find lots of options. For our purposes you need to enable -Amateur Radio AX.25 Level 2 Protocol, NET/ROM and the Serial Port -KISS Driver. For the purposes of this document I will work under the -assumption that you include them in the kernel fully, ie not as modules. -If you need to look at compiling your kernel for ax25 more fully, I would -refer to the excellent - - -

-I should say at this stage that NET/ROM is not mandatory. If you do not use it -simply ignore any instruction concerning it. - -

-Now recompile your kernel in the normal way and reboot your system. - -Installing the RPM's - -

-Now install the RPM's you downloaded, libax25 first, then ax25-tools, -then ax25-apps. - - -rpm -ivh libax25-0.0.7-7.i386.rpm -rpm -ivh ax25-tool-0.0.6-13.i386.rpm -rpm -ivh ax25-apps-0.0.4-9.i386.rpm - - -Configuration - -

-You will find the configuration files in /etc/ax25. These consist of -several files ... - - -axports -nrports -nrbroadcast -ax25d.conf -node.conf - - -

-These are the main files. You will find other files but they do not -have any use unless you are wanting to use that particular protocol, -Rose or axip for example. - -

-NOTE:- before we start it is important to realise that every interface -requires a different SSID. You should be able to follow this in the -following examples. - -axports - -

-This file sets up the ax25 ports you want to use. An example is below -for a standard TNC2 ... - - -#portname callsign baudrate paclen window description - 2m gb7mbc-2 19200 256 2 2m port on 144.900MHz - 4m gb7mbc-4 19200 256 2 4m port on 70.325MHz - - -

-Note that the portnames have to be unique. - -

-The file headings are as follows ... - - -portname - The name you will refer to the port by -callsign - The ax25 callsign you want to assign to the port -baudrate - The speed you communicate between TNC and computer -paclen - The maximum packet length for ax25 connections -window - The ax25 window parameter. This is like 'maxframe' -description - A textual description of the port - - -nrports - -

-This file sets up the netrom ports you want to use. An example is below -and includes a port for both cluster and node. You will see why we need -2 ports later ... - - -#portname callsign alias paclen description - netrom gb7mbc-8 BARE 236 Node Netrom Port - netrom2 gb7mbc-9 MBCDX 236 Cluster Netrom Port - - -

-Note that the portnames have to be unique. - -

-The file headings are as follows ... - - -portname - The name you will refer to the port by -callsign - This is the callsign that NET/ROM traffic from this - port will use -alias - The NET/ROM alias this port will be assigned -paclen - The maximum size of NET/ROM frames transmitted -description - A textual description of the port - - -nrbroadcast - -

-This file sets up the netrom broadcast qualities. An example is below ... - - -#axport min_obs def_qual worst_qual verbose - 4m 5 10 100 1 - - -

-The file headings are as follows ... - - -axport - The port name in axports that you wish to broadcast - NET/ROM on. -min_obs - The minimum obsolescence value for the port -def_qual - The default quality for the port -worst_qual - The worst quality for the port. Any routes under - this quality will be ignored -verbose - This flag determines whether you will only broadcast - your own node (0) or all known nodes (1) - - -ax25d.conf - -

-This file controls any incoming ax25 and NET/ROM connections and steers -them to the relevant program. There are lots of configuration options -you can set here, however they are well covered in the AX25-HOWTO. For -our purposes I will show a typical set of parameters. An example is -below ... - - -[gb7mbc-0 via 2m] -parameters 2 1 6 900 * 15 0 -NOCALL * * * * * * L -default * * * * * * - sysop /spider/src/client client %u ax25 - -[gb7mbc-1 via 2m] -parameters 2 1 6 900 * 15 0 -NOCALL * * * * * * L -default * * * * * * 0 root /usr/sbin/node node - -[gb7mbc-0 via 4m] -parameters 2 1 6 900 * 15 0 -NOCALL * * * * * * L -default * * * * * * - sysop /spider/src/client client %u ax25 - -[gb7mbc-1 via 4m] -parameters 2 1 6 900 * 15 0 -NOCALL * * * * * * L -default * * * * * * 0 root /usr/sbin/node node - - -parameters 1 10 * * * 3 * -NOCALL * * * * * * L -default * * * * * * - sysop /spider/src/client client %u ax25 - - -parameters 1 10 * * * 3 * -NOCALL * * * * * * L -default * * * * * * 0 root /usr/sbin/node node - - -

-There are a few things to take note of here. Firstly, all ax25 -sections are wrapped in [ ] and all NET/ROM sections are wrapped in -< >. Secondly you should be able to see that anyone who forgets to -set their callsign in a TNC and tries to connect with the standard -NOCALL set into their TNC will not connect, the 'L' means 'lockout'. -Lastly and importantly, notice the order of the sections. They are -all done in interface order. - -

-You should be able to see that the normal line for access to the -cluster is like this .. - - -default * * * * * * - sysop /spider/src/client client %u ax25 - - -

-however, if you wish your users to be able to use SSID's on their callsigns .. - - -default * * * * * * - sysop /spider/src/client client %s ax25 - - -

-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: - - -GB7DJK-2 * * * * * * - sysop /spider/src/client client gb7djk-2 ax25 -default * * * * * * - sysop /spider/src/client client %u ax25 - - -node.conf - -

-For those of you that wish to run the node, you need to set up the -node.conf file. There are a couple of additional files, node.perms is -very similar to the way ftp permissions are set up in NOS systems and -node.motd is the message anyone logging into the node will get. -The node.conf file sets all the parameters of the node as you would -expect. An example is below ... - - -# /etc/ax25/node.conf - LinuxNode configuration file -# -# see node.conf(5) - -# Idle timeout (seconds). -# -IdleTimeout 1800 - -# Timeout when gatewaying (seconds). -# -ConnTimeout 40000 - -# Visible hostname. Will be shown at telnet login. -# -HostName gb7mbc.ampr.org - -# ReConnect flag. -# -ReConnect off - -# "Local" network. -# -#LocalNet 44.139.8.48/32 - -# Command aliases. See node.conf(5) for the meaning of the uppercase -# letters in the name of the alias. -# -##Alias CAllbook 'telnet %{2:44.17.0.53} 1235 %1 s' -#Alias CONVers 'telnet %{2:oh2ti} 3600 "/n %u %{1:139}\n/w *"' -#Alias CLuster 'c hkiclh' -Alias CONV "telnet lurpac 3600" -Alias BBS "c 70cm gb7crv" -Alias DXC "telnet localhost 9000" -Alias MUD "telnet homer 4000" -##Alias TEMP "finger temp@mary.g6phf" -##Alias TNOS "c ip1 gb7mbc-5" -##Alias TUtor "telnet gb7mbc 3599" - -# Hidden ports. -# -#HiddenPorts 2 - -# External commands. See node.conf(5) for the meaning of the uppercase -# letters in the name of the extcmd. -# -# Flags: 1 Run command through pipe -# 2 Reconnected flag -# -#ExtCmd TPM 3 nobody /usr/bin/finger finger tpm -#ExtCmd ECho 1 nobody /bin/echo echo \%U \%u \%S \%s \%P \%p \%R \%r \%T \%t \%\% \%0 \%{1:foobar} \%{2} \%3 \%4 \%5 - -# Node ID. -# -NodeId "\nBARE:GB7MBC-1" -#NodeId \033[01;31m***\033[0m - -# Netrom port name. This port is used for outgoing netrom connects. -# -NrPort netrom - -# Logging level -# -LogLevel 3 - -# The escape character (CTRL-T) -# -EscapeChar ^T - -# Resolve ip numbers to addresses? -# -ResolveAddrs off - -# Node prompt. -# -#NodePrompt "\n" -#NodePrompt "%s@%h \%i> " -NodePrompt "\nBARE:GB7MBC-1 \%i > " -#NodePrompt "\a\033[36m%U\033[0m de \033[01;32m#LNODE\033[0m:\033[01;33mOH2BNS-10\033[0m> " - - -

-This should be fairly obvious I hope. - -Getting it all running - -

-Ok, now we have all the relevant files configured, the next step is to get -it all running. - -

-The first thing to do is attach the TNC's. Your TNC's should be in KISS mode -and connected to the serial ports involved. - -

-You now use the 'kissattach' command to connect the TNC's to the system like this ... - - -kissattach /dev/ttyS0 2m 44.131.96.199 -kissattach /dev/ttyS1 4m 44.131.96.199 - - -

-Assuming that 44.131.96.199 is your IP address. The devices ttyS0 and ttyS1 are com1 and -com2 respectively. Now we can set some parameters ... - - -kissparms -p 2m -t 150 -l 150 -s 50 -r 50 -kissparms -p 4m -t 150 -l 150 -s 50 -r 50 - - -

-The command 'man kissparms' will give you the explanation of the switches. - -

-Now we need to attach the NET/ROM ports in the same way ... - - -nrattach netrom -nrattach netrom2 - - -

-All of the above can be put in a file and called from /etc/rc.d/rc.local. Put all -the above commands in a file called rc.ax25 and put a line in rc.local to call it. - -

-Now you can start the daemons that set everything in motion ... - - -ax25d -netromd -i - - -

-All should now be running. All that remains is to get the node working for telnet -connections. If nothing else, this will allow you to connect to the node yourself -to check on connection status etc. There are 2 files that need to be edited. - -

-First edit /etc/services and add - - -node 3000/tcp #OH2BNS's Node Software - - -

-Assuming you want it to run on port 3000 - -

-Now cd /etc/xinetd.d and edit a new file called node. It should look like this ... - - -# default: on -# unencrypted username/password pairs for authentication. -service node -{ - socket_type = stream - wait = no - user = root - server = /usr/sbin/node - log_on_failure += USERID - disable = no -} - - -

-You now need to restart the xinetd daemon. First find out what the PID is -like so .. - - -ps auxw |grep xinetd - - -

-You will get a reply something like this ... - - -root 592 0.0 0.1 2256 620 ? S Feb07 0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid - - -

-The PID or Process ID is 592 in this case so now we can issue the command ... - - -kill -HUP 592 - - -

-All should now be operational and you should be able to log into the node by -using a telnet session to the relevant port, like so ... - - -telnet localhost 3000 - - -

-If that works, you are just about there. you should (assuming you have radios connected -to the TNC's) be able to connect out to other stations and receive incoming ax25 and -netrom connections. - -Configuration - -Allowing ax25 connects from users - -

-This is dealt with in the previous section - -Allowing telnet connects from users - -

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

-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 .... - - -spdlogin 8000/tcp # spider anonymous login port - - -

-Then add a line in /etc/inetd.conf like this .... - - -spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet - - -

-Once this is done, you need to restart inetd like this .... - - -killall -HUP inetd - - -

-Now login as sysop and cd spider/src. You can test that spider -is accepting telnet logins by issuing the following command .... - - -./client login telnet - - -

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

-Assuming all is well, then try a telnet from your linux console .... - - -telnet localhost 8000 - - -

-You should now get the login prompt and be able to login as before. - -Setting up telnet connects (from 1.47 onwards) - -

->From version 1.47 you can choose to allow the perl cluster.pl program to -allow connections directly (i.e. not via the /spider/src/client -interface program). If you are using Windows then this is the only method -available of allowing incoming telnet connections. - -

-To do this you need first to remove any line that you may previously have set -up in /etc/inetd.conf. Remember to:- - - -killall -HUP inetd - - -

-to make the change happen... - -

-Having done that, you need to copy the file -/spider/perl/Listeners.pm to /spider/local 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:- - - -@listen = ( - ["0.0.0.0", 8000], -); - - -

-As standard, the listener will listen on all interfaces simultaneously. -If you require more control than this, you can specify each interface -individually:- - - -@listen = ( - ["gb7baa.dxcluster.net", 8000], - ["44.131.16.2", 6300], -); - - -

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

-Restart the cluster.pl program to enable the listener. - -

-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. - -Setting up for AGW Engine (1.47 onwards) - -

-AGW Engine is a Windows based ax25 stack. You can connect to an AGW engine -from Linux as well as Windows based machines. - -

-In order to enable access to an AGW Engine you need to copy -/spider/perl/AGWConnect.pm to /spider/local and edit it. -Specifically you must:- - - - set $enable to 1. - set $login and $passwd to the values set up in your AGW installation. -If you haven't set any there, then you should not touch these values. - You can connect to a remote AGW engine (ie on some other machine) by changing $addr -and $port appropriately. - Restart the cluster.pl program - - - -Setting up node connects - -

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

-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 ... - - -set/node (AK1A type) -set/spider -set/dxnet -set/clx - - -

-For now, we will assume that the cluster we are going to connect to is an -AK1A type node. - -

-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 ... - - -set/node gb7baa - - -

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

-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 ... - - -./client gb7baa (using the callsign you set as a node) - - -

-You should get an initialisation string from DXSpider like this ... - - -./client gb7baa -PC38^GB7MBC^~ - - -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. - -

-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: - - -unset/node gb7baa - - -Connection scripts - -

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

-The connect scripts consist of lines which start with the following keywords -or symbols:- - - - -# are ignored, as are completely - blank lines. - -timeout 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. - -abort 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. - -connect 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! - -' 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. - -client 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]). - - -

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

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

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

-Both these examples assume that everything is set up properly at the other end. -You will find other examples in the /spider/examples directory. - -Starting the connection - -

-You start the connection, from within a sysop enabled cluster login, by typing -in the word connect followed by a script name like this .... - - -G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1 -connection to GB7DJK-1 started -G0VGS de GB7MBC 13-Dec-1998 2043Z > - - -

-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 set/debug connect first. -You should see something like this ... - - -<- 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 - - - -

-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 -before 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 ... - - -'connect' '' - - -

-In a script, this might look like ... - - -timeout 35 -abort (Busy|Sorry|Fail) -connect telnet mary 3000 -'ogin:' 'gb7mbc' -'>' 'telnet 44.131.93.96 7305' -'connect' '' - - -Telnet echo - -

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

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

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

-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. - - -Autostarting the cluster - -

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

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

-Login as root and bring up the /etc/inittab file in your favourite editor. Add -the following lines to the file near the end ... - - -##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 - - -

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

-The line required for Slackware distributions is slightly different. My thanks to -Aurelio, PA3EZL for this information. - - -DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7 - - -

-This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart -it should it crash for any reason. - -

-NB: It should be noted that /dev/tty7 is only an example. Some SuSE systems will -only accept upto tty6. It really does not matter which tty you run it on. - -

-As root type the command telinit q. DXSpider should start up -immediately. You will see the output on tty7 and if you login as sysop -you should find everything running nicely. - -Microsoft Windows Installation - -Introduction - -

-IMPORTANT: - -What you'll be left with once you've followed these instructions -is (hopefully) a working DX Spider v1.50 system that is capable -of accepting or originating "internet" connections, plus inbound -and outbound AX.25 and TCP/IP radio connections. - -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. - -The requirements - -

-The very first things you're going to need are (in order of -importance):- - - -A cup of good, strong tea -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. -Another cup of good, strong tea -If all goes according to plan, about an hour to spare -Plenty of good, strong tea - - -The system - -

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

-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. -(A recent installation used the newer ActivePerl v5.6.1, build -633 without any noticable difficulty.) You can get this from: - - -The link takes you to an initial page of System Requirements and -Software Prerequisites. If you do not have it already installed, -you can download and install the Windows Installer 2.0 for a Win98 -installation. Be forewarned, you will have to reboot your PC at the -completion of the installer's installation. - -If you already have the installer on your PC, simply click on the -Next arrow at the bottom of the page. Two clicks will finally get -you to the actual download page. The MSI version of Build 633 is -now 8.6MB in size, so make that a big cup of tea or coffee 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. - -Additional packages - -

-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: - - - -and download the following files:- - - -Data-Dumper.zip -Net-Telnet.zip -TimeDate.zip -Time-HiRes.zip -DB_File.zip - - -If this is a new installation, now would also be a good time to -install a copy of WinZip on your PC. Make yourself a convenient -directory to unpack all of these zip files into (I put mine in -"D:\ppm>" but "C:\ppm" works just as well.) and do the following -(the bits you type in are blue ). You can upzip all of the files into -the same directory. When prompted, simply overwrite the Readme file -from each zip package. 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"):- - - -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> - - -I'm not going to bother you with exhaustive details of the rest -of them, but suffice it to say you need to: - - -ppm install DB_File.ppd -ppm install Net-Telnet.ppd -ppm install TimeDate.ppd -ppm install Time-HiRes.ppd - - -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. - -Getting Spider - -

-Get the current version of the DX Spider distribution. This needs -to be v1.50 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 the latest "official" -release from: - - - -or if you want the lastest snapshot of CVS version (which is produced -every night):- - - - -This is generally the best one to go for as it is completely up to -date. However, there is always the very slight chance that it might -unstable. Generally, there will be a note on the website if this is -the case. - - -The only difference between "CVSlatest.tgz" and the latest -"official" release version is that it is more up to date. Do not confuse -the "CVSlatest.tgz" file with "Downloading from Sourceforge with CVS" - they -are two quite different things. "Downloading from Sourceforge with CVS" is -explained in a section within the Admin manual. - -

-If you go down the CVS route (ie installing WinCVS as explained in the Admin -manual and downloaded from sourceforge), then everything will be nicely -installed on your local disk. If you got the CVSlatest.tgz file, unzip -() it to "C:\". -This is an important point since paths are included within the .tgz -file. Make sure you unzip to the root directory of whichever drive you use... -"C:\" or "D:\" or .., not "C:\spider." If you double click on CVSlatest.tgz, -WinZip should open with a dialogue box that says the Archive contains a single -file (CVSlatest.tar) and asks whether WinZip should decompress it to a -temporary fold and then open it. Say "Yes" and then you will get the typical -Classical WinZip listing of files ready for extraction. Remember, extract -them to your desired root directory ("C:\" or "D:\" or ...). The following -examples assume that you put it on drive "C:\", for convenience. - -Installing the software - -

-At this point you will need to create 2 additional directories under -"C:\Spider." Make directories "C:\spider\local" and "C:\spider\local_cmd". -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:- - - -copy c:\spider\perl\DXVars.pm.issue -c:\spider\local\DXVars.pm - - -Now you'll need to edit this file using a text editor like Notepad. If nothing -else, you can simply - - -cd \spider\local - - -and then - - -notepad DXVars.pm - - -to bring up an editor window containing the file. As an absolute -minimum you must adjust the following items in DXVars.pm:- - - - $mycall - Should hold the callsign of your DX Cluster - $myname - The SysOp's first name - $myalias - the SysOp's callsign. Cannot be the same as $mycall! - $myqth - The station's geographical location (QTH). - $mylatitude - The station latitude in degrees and decimal fractions - $mylongitude - The station longitude in degrees and decimal fractions - $mylocator - The Maidenhead (or QRA) locator of the station - - -You really also ought to update the $myqth and $myemail variables. And -unless you are absolutely certain you know what you're doing, you -should change nothing else in this file. Note that if you use an "@" or -a "$" character in one of the above strings (typically in $myemail) you must -write them as "\@" or "\$". - -Incoming telnets - -

-If you want to enable inbound "TELNET" connections (or you are running -Windows 98, NT, 2000 or XP), you've got a little more work to do. From a -handy "DOS box" that's not doing anything else, do the following:- - - -copy \spider\perl\Listeners.pm \spider\local -cd \spider\local -notepad listeners.pm - - -The following line need attention:- - - -# ["0.0.0.0", 7300], - - -On my machine, I've simply uncommented the "0.0.0.0" entry by -removing the '#' from the front of the line. - -You MUST carry out this step if you are -running on a Windows 98, NT, 2000 or XP based system - -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 -amount of effort on your part to read, understand and -implement what needs to be done to set this up. - -

If your machine is connected to the internet and you don't -want to allow your machine to be visible to the outside world you -should change the "0.0.0.0" to "127.0.0.1" [which is -"localhost"]. This will then only allow connections from inside your -machine. As was said earlier: if you aren't running Win9x (or you want -to use DXTelnet or somesuch), then you need to have the machine -listening at least to "127.0.0.1" ("0.0.0.0" means all IP -addresses). - -The AGW packet engine - -

-On the assumption that you'll be using the SV2AGW Packet Engine -to interface your radios to the cluster, it would be a good idea to -download the Packet Engine software! You can get this software from: - - - -Depending upon your TNCs, you may also need to get: - - - -A couple of the tools: - - - - - -will also help with troubleshooting of the RF links themselves. - -Install and configure AGWPE. You should now create your own local copy of -AGWConnect.pm by:- - - -copy c:\spider\perl\AGWConnect.pm -c:\spider\local\AGWConnect.pm - - -and then - - -notepad AGWConnect.pm - - -to bring up an editor window containing the file. You must -consider adjusting the following items in AGWConnect.pm:- - - -$enable - set to '1' to enable AGWPE interface -$login - the login ID you chose when you set up the SV2AGW security :-) -$passwd - password that matches $login - - -The login ID and passwd only need to be set if you are accessing AGW separately -via its web interface. This interface is normally not needed for use with DXSpider. - -Setting up the initial user files - -

-Next you need to create the initial user files, etc. A tool is -supplied which will do this for you. To run the tool:- - - -cd \spider\perl -perl create_sysop.pl - - -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:- - - -perl cluster.pl - - -If you did everything you were told, your DOS window will now -hold a display which looks something like:- - - -DXSpider DX Cluster Version 1.50 -Copyright (c) 1998-2002 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) - - -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) - -If you are running Windows 9x you can access your new cluster (from -the local machine) by finding yourself another "DOS box" and doing the -following:- - - -cd \spider\perl -perl winclient.pl - - -If you are running Windows NT, 2000 or XP then winclient.pl does not -work. We don't know why other than this seems to be some kind of -incomaptibility in perl. You can achieve the same thing by telnetting -to the port you defined in Listeners.pm (7300 as default), thus:- - - -Menu->Start->Run -telnet localhost 7300 - - -On getting the login: prompt, enter your sysop callsign (the one you -put in DXVars.pm as $myalias). - -

I would recommend strongly that you obtain a better telnet -client than that which comes with windows (I use ). - -

Anyway, if you are rewarded with a display which looks something like:- - - -Hello Iain, this is GB7SJP in Amersham, Bucks running DXSpider V1.50 -Cluster: 1 nodes, 1 local / 1 total users Max users 2 Uptime 0 00:00 -M0ADI de GB7SJP 4-Mar-2001 1511Z > - - -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) - -

The interface is very basic. It is a simple command line. There are -better looking interfaces. Most of the "standard" logging and DX -Cluster access programs that are capable of connecting via a TCP or -telnet connection will work as a "Sysop Console" client. You connect -to "localhost" on the port that you defined in Listeners.pm (usually -7300). I recommend packages like . - -Connecting to other clusters - -

-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 if you -want me to set up a connection for you. - -General Information - -

-The following relates to all versions of DXSpider and is not platform related. - -The crontab file - -

-Login as sysop 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) - - -# 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') - - -

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

-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 - website -at the cron page where it is explained more fully. - -

- -