From ad09cf7c29d54881a3e1bb4b8e5da30c2f58c4b6 Mon Sep 17 00:00:00 2001 From: g0vgs Date: Thu, 3 May 2001 15:22:31 +0000 Subject: [PATCH] add installation.sgml --- sgml/installation.sgml | 1197 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1197 insertions(+) create mode 100644 sgml/installation.sgml diff --git a/sgml/installation.sgml b/sgml/installation.sgml new file mode 100644 index 00000000..2818cb06 --- /dev/null +++ b/sgml/installation.sgml @@ -0,0 +1,1197 @@ + + +
+ + + +The DXSpider Installation Manual v1.47 +Iain Philipps, G0RDI (g0rdi@77hz.com) and +Ian Maude, G0VGS, (ianmaude@btinternet.com) +Version 1.47, April 2001 revision 1.0 + + +A reference for SysOps of the DXSpider DXCluster program. + + + + + + + +Linux Installation + +Introduction + +

+This section describes the installation of DX Spider v1.47 on a + 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. + +

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

+ + Data-Dumper-2.101.tar.gz + TimeDate-1.10.tar.gz + IO-1.20.tar.gz (for perl 5.00403 and lower) + Net-Telnet-3.02.tar.gz + Curses-1.05.tar.gz + 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. + +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.47 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 + + +

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

PLEASE USE CAPITAL LETTERS FOR CALLSIGNS + +

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

+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. + +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. + + +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) + + +Configuration + +Allowing ax25 connects from users + +

+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 ... + + +default * * * * * * - sysop /spider/src/client client %u ax25 + + +or, 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 + + +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. + +

+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.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. + +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. +You can get this from:- + +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. + +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 + + +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"):- + + +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.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:- + + + +or if you want the lastest CVS version (which is produced every night) + + + +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. + +NOTE: 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. + +Installing the software + +

+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:- + + +copy c:\spider\perl\DXVars.pm.issue +c:\spider\local\DXVars.pm + + +Now you'll need to edit this file using a text editor. 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! + + +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. + +The AGW packet engine + +

+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:- + + +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 + + +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.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) + + +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:- + + +cd \spider\perl +perl winclient.pl + + +If you are rewarded with a display which looks something like:- + + +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 > + + +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) + +Incoming telnets + +

+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:- + + +copy \spider\perl\listeners.pm \spider\local +cd \spider\local +notepad listeners.pm + + +The following lines 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. + +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. + +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 Email 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') if 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. + +

-- 2.43.0