yet more doc changes
[spider.git] / html / adminmanual-3.html
diff --git a/html/adminmanual-3.html b/html/adminmanual-3.html
deleted file mode 100644 (file)
index eb8efa9..0000000
+++ /dev/null
@@ -1,477 +0,0 @@
-<!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 and Administration Manual: Configuration</TITLE>
- <LINK HREF="adminmanual-4.html" REL=next>
- <LINK HREF="adminmanual-2.html" REL=previous>
- <LINK HREF="adminmanual.html#toc3" REL=contents>
-<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
-</HEAD>
-<BODY>
-<A HREF="adminmanual-4.html">Next</A>
-<A HREF="adminmanual-2.html">Previous</A>
-<A HREF="adminmanual.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 &quot;0.0.0.0&quot; 
-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>
-&lt;- 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
-&lt;- O GB7DJK-1 telnet
--> B GB7DJK-1 0
-GB7DJK-1 channel func  state 0 -> init
-&lt;- D GB7DJK-1 
-&lt;- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
-&lt;- D GB7DJK-1 PC38^GB7DJK-1^~
-&lt;- 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>
-<HR>
-<A HREF="adminmanual-4.html">Next</A>
-<A HREF="adminmanual-2.html">Previous</A>
-<A HREF="adminmanual.html#toc3">Contents</A>
-</BODY>
-</HTML>