-<P>
-You should now get the login prompt and be able to login as before.
-
-<sect1>Setting up node connects
-
-<P>
-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.
-
-<P>
-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 ...
-
-<tscreen><verb>
-set/node (AK1A type)
-set/spider
-set/dxnet
-set/clx
-</verb></tscreen>
-
-<P>
-For now, we will assume that the cluster we are going to connect to is an
-AK1A type node.
-
-<P>
-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 ...
-
-<tscreen><verb>
-set/node gb7baa
-</verb></tscreen>
-
-<P>
-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.
-
-<P>
-That is now set, it is as simple as that. To prove it, login on yet another
-console as sysop and issue the command ...
-
-<tscreen><verb>
-client.pl gb7baa (using the callsign you set as a node)
-</verb></tscreen>
-
-<P>
-You should get an initialisation string from DXSpider like this ...
-
-<tscreen><verb>
-client.pl gb7baa
-PC38^GB7MBC^~
-</verb></tscreen>
-
-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.
-
-<sect1>Connection scripts
-
-<P>
-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.
-
-<P>
-The connect scripts consist of lines which start with the following keywords
-or symbols:-
-
-<verb>
-
-# All lines starting with a # are ignored, as are completely
- blank lines.
-
-timeout 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 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 connect followed by ax25 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 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]).
-</verb>
-
-
-There are many possible ways to configure the script but here are two examples,
-one for a NETRom/AX25 connect and one for tcp/ip.
-
-<tscreen><verb>
-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
-</verb></tscreen>
-
-<P>
-
-<tscreen><verb>
-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
-</verb></tscreen>
-
-<P>
-Both these examples assume that everything is set up properly at the other end.
-You will find other examples in the /spider/examples directory.
-
-<sect1>Starting the connection
-
-<P>
-You start the connection, from within a sysop enabled cluster login, by typing
-in the word <em>connect</em> followed by a script name like this ....
-
-<tscreen><verb>
-G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
-connection to GB7DJK-1 started
-G0VGS de GB7MBC 13-Dec-1998 2043Z >
-</verb></tscreen>
-
-This will start a connection using the script called <em>gb7djk-1</em>. You can
-follow the connection by watching the term or console from where you started
-<em>cluster.pl</em>. You should see something like this ...
-
-<tscreen><verb>
-<- 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
-
-</verb></tscreen>
-
-<P>
-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
-<it>before</it> 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 ...
-
-<tscreen><verb>
-'connect' ''
-</verb></tscreen>
-
-<P>
-In a script, this might look like ...
-
-<tscreen><verb>
-timeout 35
-abort (Busy|Sorry|Fail)
-connect telnet mary 3000
-'ogin:' 'gb7mbc'
-'>' 'telnet 44.131.93.96 7305'
-'connect' ''
-</verb></tscreen>
-
-<sect1>Telnet echo
-
-<P>
-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.
-
-<P>
-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 8000, this negotiation does
-not happen and therefore no echo should be present.
-
-<P>
-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 ...
-
-<tscreen><verb>
-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' ''
-</verb></tscreen>
-
-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.
-
-
-<sect>Automating things
-
-<P>
-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.
-
-<sect1>Autostarting the cluster
-
-<P>
-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.
-
-<P>
-Login as root and bring up the /etc/inittab file in your favourite editor. Add
-the following lines to the file near the end ...