- 10.1 Creating databases
- 10.2 Importing databases
- 10.3 Checking available databases
- 10.4 Looking up databases
- 10.5 Removing databases
-
- 11. Information, files and useful programs
-
- 11.1 MOTD
- 11.2 Downtime message
- 11.3 Other text messages
- 11.4 The Aliases file
- 11.5 Console.pl
- 11.6 Updating kepler data
- 11.7 The QRZ callbook
-
- 12. CVS
-
- 13. The DXSpider command set
-
- 13.1 accept/announce (0)
- 13.2 accept/announce (extended for sysops) (8)
- 13.3 accept/spots (0)
- 13.4 accept/spots (extended for sysops) (8)
- 13.5 accept/wcy (0)
- 13.6 accept/wcy (extended for sysops) (8)
- 13.7 accept/wwv (0)
- 13.8 accept/wwv (extended for sysops) (8)
- 13.9 announce (0)
- 13.10 announce full (0)
- 13.11 announce sysop (5)
- 13.12 apropos (0)
- 13.13 bye (0)
- 13.14 catchup (5)
- 13.15 clear/spots (0)
- 13.16 connect (5)
- 13.17 dbavail (0)
- 13.18 dbcreate (9)
- 13.19 dbimport (9)
- 13.20 dbremove (9)
- 13.21 dbshow (0)
- 13.22 debug (9)
- 13.23 directory (0)
- 13.24 directory (extended for sysops) (5)
- 13.25 disconnect (8)
- 13.26 dx (0)
- 13.27 export (9)
- 13.28 export_users (9)
- 13.29 forward/latlong (8)
- 13.30 forward/opername (1)
- 13.31 help (0)
- 13.32 init (5)
- 13.33 kill (0)
- 13.34 kill (5)
- 13.35 kill full (5)
- 13.36 links (0)
- 13.37 load/aliases (9)
- 13.38 load/baddx (9)
- 13.39 load/badmsg (9)
- 13.40 load/badwords (9)
- 13.41 load/bands (9)
- 13.42 load/cmd_cache (9)
- 13.43 load/forward (9)
- 13.44 load/messages (9)
- 13.45 load/prefixes (9)
- 13.46 merge (5)
- 13.47 msg (9)
- 13.48 pc (8)
- 13.49 ping (1)
- 13.50 rcmd (1)
- 13.51 read (0)
- 13.52 read (extended for sysops) (5)
- 13.53 reject/announce
- 13.54 reject/announce (extended for sysops) (8)
- 13.55 reject/spots (0)
- 13.56 reject/spots (extended for sysops) (8)
- 13.57 reject/wcy (0)
- 13.58 reject/wcy (extended for sysops) (8)
- 13.59 reject/wwv (0)
- 13.60 reject/wwv (extended for sysops) (8)
- 13.61 reply (0)
- 13.62 send (0)
- 13.63 set/address (0)
- 13.64 set/announce (0)
- 13.65 set/arcluster (5)
- 13.66 set/baddx (8)
- 13.67 set/badnode (6)
- 13.68 set/badspotter (8)
- 13.69 set/beep (0)
- 13.70 set/clx (5)
- 13.71 set/debug (9)
- 13.72 set/dx (0)
- 13.73 set/dxgrid (0)
- 13.74 set/dxnet (5)
- 13.75 set/echo (0)
- 13.76 set/here (0)
- 13.77 set/homenode (0)
- 13.78 set/hops (8)
- 13.79 set/isolate (9)
- 13.80 set/language (0)
- 13.81 set/location (0)
- 13.82 set/sys_location (9)
- 13.83 set/logininfo (0)
- 13.84 set/lockout (9)
- 13.85 set/name (0)
- 13.86 set/node (9)
- 13.87 set/obscount (9)
- 13.88 set/page (0)
- 13.89 set/password (9)
- 13.90 set/pinginterval (9)
- 13.91 set/privilege (9)
- 13.92 set/spider (5)
- 13.93 set/sys_qra (9)
- 13.94 set/qra (0)
- 13.95 set/qth (0)
- 13.96 set/talk (0)
- 13.97 set/wcy (0)
- 13.98 set/wwv (0)
- 13.99 set/wx (0)
- 13.100 show/baddx (1)
- 13.101 show/badnode (6)
- 13.102 show/badspotter (1)
- 13.103 show/date (0)
- 13.104 show/debug (9)
- 13.105 show/dx (0)
- 13.106 show/dxcc (0)
- 13.107 show/files (0)
- 13.108 show/filter (0)
- 13.109 show/filter (extended for sysops) (5)
- 13.110 show/hops (8)
- 13.111 show/isolate (1)
- 13.112 show/lockout (9)
- 13.113 show/log (8)
- 13.114 show/moon (0)
- 13.115 show/muf (0)
- 13.116 show/node (1)
- 13.117 show/prefix (0)
- 13.118 show/program (5)
- 13.119 show/qra (0)
- 13.120 show/qrz (0)
- 13.121 show/route (0)
- 13.122 show/satellite (0)
- 13.123 show/sun (0)
- 13.124 show/time (0)
- 13.125 show/wcy (0)
- 13.126 show/wwv (0)
- 13.127 shutdown (5)
- 13.128 spoof (9)
- 13.129 stat/db (5)
- 13.130 stat/channel (5)
- 13.131 stat/msg (5)
- 13.132 stat/user (5)
- 13.133 sysop (0)
- 13.134 talk (0)
- 13.135 type (0)
- 13.136 who (0)
- 13.137 wx (0)
- 13.138 wx (enhanced for sysops) (5)
-
-
- ______________________________________________________________________
-
- 1\b1.\b. I\bIn\bns\bst\bta\bal\bll\bla\bat\bti\bio\bon\bn (\b(O\bOr\bri\big\bgi\bin\bna\bal\bl v\bve\ber\brs\bsi\bio\bon\bn b\bby\by I\bIa\bai\bin\bn P\bPh\bhi\bil\bli\bip\bpp\bps\bs,\b, G\bG0\b0R\bRD\bDI\bI)\b)
-
- 1\b1.\b.1\b1.\b. I\bIn\bnt\btr\bro\bod\bdu\buc\bct\bti\bio\bon\bn
-
- This section describes the installation of DX Spider v1.46 on a RedHat
- Linux Distribution. Wherever possible I will try to include
- differences for other distributions. I do not intend to try and cover
- the installation of Linux or the setup of the AX25 utilities. If you
- need help on this then read Iains original installation guide that
- comes with the Spider distribution.
-
-
- I am assuming a general knowledge of Linux and its commands. You
- should know how to use _\bt_\ba_\br and how to edit files using your favourite
- editor.
-
-
- The crucial ingredient for all of this is Perl. Earlier versions of
- Spider required perl 5.004, however it is now _\bS_\bT_\bR_\bO_\bN_\bG_\bL_\bY 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 http://www.cpan.org/CPAN.html ...
-
-
-
- +\bo Data-Dumper-2.101.tar.gz
-
- +\bo TimeDate-1.10.tar.gz
-
- +\bo IO-1.20.tar.gz (for perl 5.00403 and lower)
-
- +\bo Net-Telnet-3.02.tar.gz
-
-
- +\bo Curses-1.05.tar.gz
-
- +\bo Time-HiRes-01.20.tar.gz
-
-
-
- _\bD_\bo get the latest versions of these packages and install them but use
- the above list as the earliest versions usable.
-
-
- 1\b1.\b.2\b2.\b. P\bPr\bre\bep\bpa\bar\bra\bat\bti\bio\bon\bn
-
- 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.46 for this section but of course you would use the latest
- version.
-
-
- Login as root and create a user to run the cluster under. _\bU_\bN_\bD_\bE_\bR _\bN_\bO
- _\bC_\bI_\bR_\bC_\bU_\bM_\bS_\bT_\bA_\bN_\bC_\bE_\bS _\bU_\bS_\bE _\bR_\bO_\bO_\bT _\bA_\bS _\bT_\bH_\bI_\bS _\bU_\bS_\bE_\bR_\b!. I am going to use the name
- _\bs_\by_\bs_\bo_\bp. 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
-
-
-
-
-
- 1\b1.\b.3\b3.\b. I\bIn\bns\bst\bta\bal\bll\bli\bin\bng\bg t\bth\bhe\be s\bso\bof\bft\btw\bwa\bar\bre\be
-
- 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.46.tar.gz
- # ln -s ~sysop/spider /spider
- # groupadd -g 251 spider (or another number)
-
-
-
-
- If you do not have the command _\bg_\br_\bo_\bu_\bp_\ba_\bd_\bd 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 _\bs_\bp_\bi_\bd_\be_\br 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 _\bl_\bo_\bc_\ba_\bt_\be command
- and alter the permissions with the _\bc_\bh_\bm_\bo_\bd command like this ..
-
-
-
- # chown root ax25_call netrom_call
- # chmod 4775 ax25_call netrom_call
-
-
-
-
-
- 1\b1.\b.4\b4.\b. S\bSe\bet\btt\bti\bin\bng\bg c\bca\bal\bll\bls\bsi\big\bgn\bns\bs e\bet\btc\bc
-
- Now login to your machine as the user you created earlier. In my case
- that user is called _\bs_\by_\bs_\bo_\bp. 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.
-
-
- P\bPL\bLE\bEA\bAS\bSE\bE U\bUS\bSE\bE C\bCA\bAP\bPI\bIT\bTA\bAL\bL L\bLE\bET\bTT\bTE\bER\bRS\bS F\bFO\bOR\bR C\bCA\bAL\bLL\bLS\bSI\bIG\bGN\bNS\bS
-
-
- 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
-
-
-
-
-
- 1\b1.\b.5\b5.\b. S\bSt\bta\bar\brt\bti\bin\bng\bg u\bup\bp f\bfo\bor\br t\bth\bhe\be f\bfi\bir\brs\bst\bt t\bti\bim\bme\be
-
- 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.46
- 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 _\bs_\by_\bs_\bo_\bp 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.
-
-
- 1\b1.\b.6\b6.\b. T\bTh\bhe\be C\bCl\bli\bie\ben\bnt\bt p\bpr\bro\bog\bgr\bra\bam\bm
-
- 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 _\bi_\bn_\bc_\bo_\bm_\bi_\bn_\bg connects at the moment. Before you can
- use it though it has to be "made". CD to /spider/src and type _\bm_\ba_\bk_\be.
- You should see the output on your screen and hopefully now have a
- small C program called _\bc_\bl_\bi_\be_\bn_\bt. Leave it in this directory.
-
-
-
- 2\b2.\b. Q\bQu\bui\bic\bck\bk i\bin\bns\bst\bta\bal\bll\bla\bat\bti\bio\bon\bn g\bgu\bui\bid\bde\be
-
- 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.
-
-
- +\bo Login as root
-
- +\bo Get the additional CPAN modules and install them (root)
-
- +\bo Create the "sysop" user and set a password (root)
-
- +\bo Put the Spider tarball in sysop and untar it (root)
-
- +\bo ln -s sysop/spider /spider (root)
-
- +\bo groupadd -g 251 spider (root)
-
- +\bo Add any more users you need to the group entry in /etc/group (root)
-
- +\bo Set the permissions on the spider tree (root)
-
- +\bo Fix permissions on ax25_call and netrom_call (root)
-
- +\bo Login as the sysop user
-
- +\bo cd to /spider (sysop)
-
- +\bo mkdir local (sysop)
-
- +\bo mkdir local_cmd (sysop)
-
- +\bo cp perl/DXVars.pm.issue local/DXVars.pm (sysop)
-
- +\bo cd to /spider/local and edit DXVars to set your details (sysop)
-
- +\bo cd ../perl (sysop)
-
- +\bo ./create_sysop.pl (sysop)
-
- +\bo ./cluster.pl (sysop)
-
- Spider should now be running and you should be able to login using the
- client program.
-
-
- +\bo Login as root
-
- +\bo Enter the correct line in ax25d.conf (root)
-
- +\bo Enter the correct line in /etc/services (root)
-
- +\bo Enter the correct line in /etc/inetd.conf (root)
-
- +\bo killall -HUP inetd (root)
-
- Spider should now be able to accept logins via telnet, netrom and
- ax25.
-
-
- +\bo Login as sysop
-
- +\bo Start the cluster (sysop)
-
- +\bo set/node and type for links (sysop)
-
- +\bo Write any connect scripts (sysop)
-
- +\bo Edit /spider/crontab as required (sysop)
-
- +\bo Edit any other files as necessary (sysop)
-
- +\bo Set filters, hops and forwarding files (sysop)
-
- +\bo Login as root
-
- +\bo Enter the correct line in /etc/inittab (root)
-
-
- 3\b3.\b. C\bCo\bon\bnf\bfi\big\bgu\bur\bra\bat\bti\bio\bon\bn
-
-
-
-
- 3\b3.\b.1\b1.\b. A\bAl\bll\blo\bow\bwi\bin\bng\bg a\bax\bx2\b25\b5 c\bco\bon\bnn\bne\bec\bct\bts\bs f\bfr\bro\bom\bm u\bus\bse\ber\brs\bs
-
- 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 owuld 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
-
-
-
-
-
- 3\b3.\b.2\b2.\b. A\bAl\bll\blo\bow\bwi\bin\bng\bg t\bte\bel\bln\bne\bet\bt c\bco\bon\bnn\bne\bec\bct\bts\bs f\bfr\bro\bom\bm u\bus\bse\ber\brs\bs
-
-
- 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 7300/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 _\bs_\by_\bs_\bo_\bp 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 7300
-
-
-
-
-
- You should now get the login prompt and be able to login as before.
-
-
- 3\b3.\b.3\b3.\b. S\bSe\bet\btt\bti\bin\bng\bg u\bup\bp t\bte\bel\bln\bne\bet\bt c\bco\bon\bnn\bne\bec\bct\bts\bs (\b(f\bfr\bro\bom\bm 1\b1.\b.4\b47\b7 o\bon\bnw\bwa\bar\brd\bds\bs)\b)
-
- From version 1.47 you can chose to allow the perl cluster.pl program
- to allow connections direct (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 then 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 "0.0.0.0" and select the correct
- port to listen on. So that it looks like this:-
- @listen = (
- ["0.0.0.0", 7300],
- );
-
-
-
-
-
- As standard, the listener will listen on all interfaces
- simultaniously. If you require more control than this, you can specify
- each interface individually:-
-
-
-
- @listen = (
- ["gb7baa.dxcluster.net", 7300],
- ["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 which 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.
-
-
- 3\b3.\b.4\b4.\b. S\bSe\bet\btt\bti\bin\bng\bg u\bup\bp f\bfo\bor\br A\bAG\bGW\bW E\bEn\bng\bgi\bin\bne\be (\b(1\b1.\b.4\b47\b7 o\bon\bnw\bwa\bar\brd\bds\bs)\b)
-
- 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:-
-
-
- +\bo set $enable to 1.
-
- +\bo 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.
-
- +\bo You can connect to a remote AGW engine (ie on some other machine)
- by changing $addr and $port appropriately.
-
- +\bo Restart the cluster.pl program
-
-
-
-
-
-
-
- 3\b3.\b.5\b5.\b. S\bSe\bet\btt\bti\bin\bng\bg u\bup\bp n\bno\bod\bde\be c\bco\bon\bnn\bne\bec\bct\bts\bs
-
- 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
-
-
-
-
-
- 3\b3.\b.6\b6.\b. C\bCo\bon\bnn\bne\bec\bct\bti\bio\bon\bn s\bsc\bcr\bri\bip\bpt\bts\bs
-
- 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:-
-
-
-
- #\b# All lines starting with a # are ignored, as are completely blank
- lines.
-
-
- t\bti\bim\bme\beo\bou\but\bt
- 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.
-
-
- a\bab\bbo\bor\brt\bt
- 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.
-
-
- c\bco\bon\bnn\bne\bec\bct\bt
- 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!
-
-
- '\b' 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.
-
-
- c\bcl\bli\bie\ben\bnt\bt
- 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
- # you can leave this out if you call the script 'gb7dxm'
- client gb7dxm ax25
-
-
-
-
-
-
-
-
- timeout 60
- abort (Busy|Sorry|Fail)
- # this does exactly the same as the previous example
- # the '1' is the AGW port number to connect thru for g1tlh
- connect agw 1 g1tlh
- # you can leave this out if you call the script 'gb7dxm'
- client gb7dxm ax25
-
-
-
-
-
-
-
-
- timeout 15
- connect telnet dirkl.tobit.co.uk
- # 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.
-
-
-
-
- 3\b3.\b.7\b7.\b. S\bSt\bta\bar\brt\bti\bin\bng\bg t\bth\bhe\be c\bco\bon\bnn\bne\bec\bct\bti\bio\bon\bn
-
- You start the connection, from within a sysop enabled cluster login,
- by typing in the word _\bc_\bo_\bn_\bn_\be_\bc_\bt 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 _\bg_\bb_\b7_\bd_\bj_\bk_\b-_\b1. You
- can follow the connection by watching the term or console from where
- you started _\bc_\bl_\bu_\bs_\bt_\be_\br_\b._\bp_\bl. 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 _\bb_\be_\bf_\bo_\br_\be 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 ...
-
-
-
-
-
-
- In a script, this might look like ...
-
-
-
- timeout 35
- abort (Busy|Sorry|Fail)
- connect telnet mary 3000
-
-
-
-
-
- 3\b3.\b.8\b8.\b. T\bTe\bel\bln\bne\bet\bt e\bec\bch\bho\bo
-
- 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
-
-
-
-
- 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.
-
-
-
- 4\b4.\b. A\bAu\but\bto\bom\bma\bat\bti\bin\bng\bg t\bth\bhi\bin\bng\bgs\bs
-
- 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 and if connection scripts fail they have to be
- started again manually too, not much use if you are not at the
- console! So, in this section we will automate both. Firstly starting
- the cluster.
-
-
- 4\b4.\b.1\b1.\b. A\bAu\but\bto\bos\bst\bta\bar\brt\bti\bin\bng\bg t\bth\bhe\be c\bcl\blu\bus\bst\bte\ber\br
-
- 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 _\bt_\be_\bl_\bi_\bn_\bi_\bt _\bq. DXSpider should start up
- immediately. You will see the output on tty7 and if you login as
- _\bs_\by_\bs_\bo_\bp you should find everything running nicely.
-
-
- So far so good, now to automate script connections...
-
-
- 4\b4.\b.2\b2.\b. T\bTh\bhe\be c\bcr\bro\bon\bnt\bta\bab\bb f\bfi\bil\ble\be
-
- Login as _\bs_\by_\bs_\bo_\bp 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)