mirror of
git://scm.dxcluster.org/scm/spider
synced 2024-09-21 07:47:10 +00:00
533 lines
18 KiB
HTML
533 lines
18 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
|
|
<TITLE>The DXSpider Installation Manual v1.50: Configuration</TITLE>
|
|
<LINK HREF="installation_en-5.html" REL=next>
|
|
<LINK HREF="installation_en-3.html" REL=previous>
|
|
<LINK HREF="installation_en.html#toc4" REL=contents>
|
|
<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="installation_en-5.html">Next</A>
|
|
<A HREF="installation_en-3.html">Previous</A>
|
|
<A HREF="installation_en.html#toc4">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s4">4.</A> <A HREF="installation_en.html#toc4">Configuration</A></H2>
|
|
|
|
<H2><A NAME="ss4.1">4.1</A> <A HREF="installation_en.html#toc4.1">Allowing ax25 connects from users</A>
|
|
</H2>
|
|
|
|
<P>This is dealt with in the previous section</P>
|
|
|
|
<H2><A NAME="ss4.2">4.2</A> <A HREF="installation_en.html#toc4.2">Setting up telnet connects (from 1.47 onwards)</A>
|
|
</H2>
|
|
|
|
<P>>From version 1.47 you can choose to allow the perl cluster.pl program to
|
|
allow connections directly (i.e. not via the <CODE>/spider/src/client</CODE>
|
|
interface program). If you are using Windows then this is the only method
|
|
available of allowing incoming telnet connections.</P>
|
|
|
|
<P>to make the change happen...</P>
|
|
|
|
<P>Having done that, you need to copy the file
|
|
<EM>/spider/perl/Listeners.pm</EM> to <EM>/spider/local</EM> and
|
|
then edit it. You will need to uncomment the line containing "0.0.0.0"
|
|
and select the correct port to listen on.</P>
|
|
<P>It comes out of the box looking something like:-</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
@listen = (
|
|
# ["0.0.0.0", 7300],
|
|
);
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Change it so that it looks like this:-</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
@listen = (
|
|
["0.0.0.0", 7300],
|
|
);
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>Later versions have more comments in the Listeners.pm file that
|
|
are designed to help you remove the correct '#' character.</P>
|
|
|
|
<P>As standard, the listener will listen on all interfaces simultaneously.
|
|
If you require more control than this, you can specify each interface
|
|
individually:-</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
@listen = (
|
|
["gb7baa.dxcluster.net", 7300],
|
|
["44.131.16.2", 6300],
|
|
);
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>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.</P>
|
|
|
|
<P>Restart the cluster.pl program to enable the listener.</P>
|
|
|
|
<P>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. </P>
|
|
|
|
<H2><A NAME="ss4.3">4.3</A> <A HREF="installation_en.html#toc4.3">Allowing telnet connects from users (before version 1.47 or for special purposes)</A>
|
|
</H2>
|
|
|
|
<P>
|
|
>From version 1.47 there is a new (more efficient) way of doing this
|
|
(see previous section) but, if you prefer, the method of doing it described
|
|
here will continue to work just fine.</P>
|
|
|
|
<P>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 ....</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
spdlogin 8000/tcp # spider anonymous login port
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>Then add a line in /etc/inetd.conf like this ....</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>Once this is done, you need to restart inetd like this ....</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
killall -HUP inetd
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>Now login as <EM>sysop</EM> and cd spider/src. You can test that spider
|
|
is accepting telnet logins by issuing the following command ....</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
./client login telnet
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>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.</P>
|
|
|
|
<P>Assuming all is well, then try a telnet from your linux console ....</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
telnet localhost 8000
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>You should now get the login prompt and be able to login as before.</P>
|
|
|
|
|
|
<H2><A NAME="ss4.4">4.4</A> <A HREF="installation_en.html#toc4.4">Setting up for AGW Engine (1.47 onwards)</A>
|
|
</H2>
|
|
|
|
<P>AGW Engine is a Windows based ax25 stack. You can connect to an AGW engine
|
|
from Linux as well as Windows based machines.</P>
|
|
|
|
<P>In order to enable access to an AGW Engine you need to copy
|
|
<EM>/spider/perl/AGWConnect.pm</EM> to <EM>/spider/local</EM> and edit it.
|
|
Specifically you must:-</P>
|
|
<P>
|
|
<UL>
|
|
<LI> set <CODE>$enable</CODE> to 1.</LI>
|
|
<LI> set <CODE>$login</CODE> and <CODE>$passwd</CODE> to the values set up in your AGW installation.
|
|
If you haven't set any there, then you should not touch these values.</LI>
|
|
<LI> You can connect to a remote AGW engine (ie on some other machine) by changing <CODE>$addr</CODE>
|
|
and <CODE>$port</CODE> appropriately.</LI>
|
|
<LI> Restart the cluster.pl program</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="ss4.5">4.5</A> <A HREF="installation_en.html#toc4.5">Setting up node connects</A>
|
|
</H2>
|
|
|
|
<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>
|
|
|
|
<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 ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
set/node (AK1A type)
|
|
set/spider
|
|
set/dxnet
|
|
set/clx
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>For now, we will assume that the cluster we are going to connect to is an
|
|
AK1A type node.</P>
|
|
|
|
<P>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 ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
set/node gb7baa
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<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>
|
|
|
|
<P>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 ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
./client gb7baa (using the callsign you set as a node)
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>You should get an initialisation string from DXSpider like this ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
./client gb7baa
|
|
PC38^GB7MBC^~
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>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.</P>
|
|
|
|
<P>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:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
unset/node gb7baa
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H2><A NAME="ss4.6">4.6</A> <A HREF="installation_en.html#toc4.6">Connection scripts</A>
|
|
</H2>
|
|
|
|
<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>
|
|
|
|
<P>The connect scripts consist of lines which start with the following keywords
|
|
or symbols:-</P>
|
|
<P>
|
|
<DL>
|
|
|
|
<DT><B>#</B><DD><P>All lines starting with a <CODE>#</CODE> are ignored, as are completely
|
|
blank lines.</P>
|
|
|
|
<DT><B>timeout</B><DD><P><CODE>timeout</CODE> 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.</P>
|
|
|
|
<DT><B>abort</B><DD><P><CODE>abort</CODE> 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.</P>
|
|
|
|
<DT><B>connect</B><DD><P><CODE>connect</CODE> 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!</P>
|
|
|
|
<DT><B>'</B><DD><P><CODE>'</CODE> 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. </P>
|
|
|
|
<DT><B>client</B><DD><P><CODE>client</CODE> 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]).</P>
|
|
</DL>
|
|
</P>
|
|
|
|
<P>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. </P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<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.</P>
|
|
|
|
<H2><A NAME="ss4.7">4.7</A> <A HREF="installation_en.html#toc4.7">Starting the connection</A>
|
|
</H2>
|
|
|
|
<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 ....</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
|
|
connection to GB7DJK-1 started
|
|
G0VGS de GB7MBC 13-Dec-1998 2043Z >
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>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>. From version 1.47 onwards, you will need to <CODE>set/debug connect</CODE> first.
|
|
You should see something like this ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
<- 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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<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
|
|
<I>before</I> 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 ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
'connect' ''
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>In a script, this might look like ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
timeout 35
|
|
abort (Busy|Sorry|Fail)
|
|
connect telnet mary 3000
|
|
'ogin:' 'gb7mbc'
|
|
'>' 'telnet 44.131.93.96 7305'
|
|
'connect' ''
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H2><A NAME="ss4.8">4.8</A> <A HREF="installation_en.html#toc4.8">Telnet echo</A>
|
|
</H2>
|
|
|
|
<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>
|
|
|
|
<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 7300, this negotiation does
|
|
not happen and therefore no echo should be present.</P>
|
|
|
|
<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 ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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' ''
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>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.</P>
|
|
|
|
|
|
<H2><A NAME="ss4.9">4.9</A> <A HREF="installation_en.html#toc4.9">Autostarting the cluster</A>
|
|
</H2>
|
|
|
|
<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. It
|
|
would be much easier to have it start automatically. </P>
|
|
|
|
<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>
|
|
|
|
<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 ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
##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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>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 ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>The line required for Slackware distributions is slightly different. My thanks to
|
|
Aurelio, PA3EZL for this information.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart
|
|
it should it crash for any reason.</P>
|
|
|
|
<P>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.</P>
|
|
|
|
<P>As root type the command <EM>telinit q</EM>. DXSpider should start up
|
|
immediately. You will see the output on tty7 and if you login as <EM>sysop</EM>
|
|
you should find everything running nicely.</P>
|
|
|
|
<HR>
|
|
<A HREF="installation_en-5.html">Next</A>
|
|
<A HREF="installation_en-3.html">Previous</A>
|
|
<A HREF="installation_en.html#toc4">Contents</A>
|
|
</BODY>
|
|
</HTML>
|