- 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.35
- 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/perl. Now issue the following command ...
-
-
-
- $ client.pl
-
-
-
-
-
- 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.
-
-
- 2\b2.\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.
-
-
- 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
-
-
-
-
-
- 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
-
- 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
-
-
-
-
-
- This needs to be added above the standard services such as ftp, telnet
- etc. 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/perl. You can test that spider is
- accepting telnet logins by issuing the following command ....
-
-
-
- client.pl 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.
-
-
- 3\b3.\b.3\b3.\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.pl. 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 and issue the command ...
-
-
-
- client.pl gb7baa (using the callsign you set as a node)