--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>The DXSpider Installation Manual v1.47: Configuration</TITLE>
+ <LINK HREF="installation-4.html" REL=next>
+ <LINK HREF="installation-2.html" REL=previous>
+ <LINK HREF="installation.html#toc3" REL=contents>
+<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
+</HEAD>
+<BODY>
+<A HREF="installation-4.html">Next</A>
+<A HREF="installation-2.html">Previous</A>
+<A HREF="installation.html#toc3">Contents</A>
+<HR>
+<H2><A NAME="s3">3. Configuration</A></H2>
+
+<H2><A NAME="ss3.1">3.1 Allowing ax25 connects from users</A>
+</H2>
+
+<P>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 ...
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+default * * * * * * - sysop /spider/src/client client %u ax25
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>or, if you wish your users to be able to use SSID's on their callsigns ..
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+default * * * * * * - sysop /spider/src/client client %s ax25
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>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:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+GB7DJK-2 * * * * * * - sysop /spider/src/client client gb7djk-2 ax25
+default * * * * * * - sysop /spider/src/client client %u ax25
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>
+<H2><A NAME="ss3.2">3.2 Allowing telnet connects from users </A>
+</H2>
+
+<P>
+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.
+<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>
+<BLOCKQUOTE><CODE>
+<PRE>
+spdlogin 8000/tcp # spider anonymous login port
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Then add a line in /etc/inetd.conf like this ....
+<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>
+<BLOCKQUOTE><CODE>
+<PRE>
+killall -HUP inetd
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>
+<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>
+<BLOCKQUOTE><CODE>
+<PRE>
+./client login telnet
+</PRE>
+</CODE></BLOCKQUOTE>
+<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>
+<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="ss3.3">3.3 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 do this you need first to remove any line that you may previously have set
+up in /etc/inetd.conf. Remember to:-
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+killall -HUP inetd
+</PRE>
+</CODE></BLOCKQUOTE>
+<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. So that it looks like this:-
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+@listen = (
+ ["0.0.0.0", 8000],
+);
+</PRE>
+</CODE></BLOCKQUOTE>
+<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>
+<BLOCKQUOTE><CODE>
+<PRE>
+@listen = (
+ ["gb7baa.dxcluster.net", 8000],
+ ["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="ss3.4">3.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>
+<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>
+<P>
+<H2><A NAME="ss3.5">3.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>
+<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>
+<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>
+<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>
+<BLOCKQUOTE><CODE>
+<PRE>
+./client gb7baa
+PC38^GB7MBC^~
+</PRE>
+</CODE></BLOCKQUOTE>
+<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>
+<BLOCKQUOTE><CODE>
+<PRE>
+unset/node gb7baa
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>
+<H2><A NAME="ss3.6">3.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>
+<DL>
+<P>
+<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]).
+</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>
+<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>
+<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>
+<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="ss3.7">3.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>
+<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>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>
+<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>
+<BLOCKQUOTE><CODE>
+<PRE>
+'connect' ''
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>
+<P>In a script, this might look like ...
+<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="ss3.8">3.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>
+<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>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>
+<P>
+<H2><A NAME="ss3.9">3.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>
+<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>
+<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>
+<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>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-4.html">Next</A>
+<A HREF="installation-2.html">Previous</A>
+<A HREF="installation.html#toc3">Contents</A>
+</BODY>
+</HTML>
projects / spider.git / blobdiff