This is dealt with in the previous section
- -->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.
- -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
-
-Once this is done, you need to restart inetd like this ....
--
-
-killall -HUP inetd
-
-Now login as sysop and cd spider/src. You can test that spider -is accepting telnet logins by issuing the following command ....
--
-
-./client 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.
- ->From version 1.47 you can choose to allow the perl cluster.pl program to
-allow connections directly (i.e. not via the /spider/src/client
-interface program). If you are using Windows then this is the only method
-available of allowing incoming telnet connections.
To do this you need first to remove any line that you may previously have set -up in /etc/inetd.conf. Remember to:-
--
-
-killall -HUP inetd
-
-to make the change happen...
- -Having done that, you need to copy the file -/spider/perl/Listeners.pm to /spider/local 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:-
--
-
-@listen = (
- ["0.0.0.0", 8000],
-);
-
-As standard, the listener will listen on all interfaces simultaneously. -If you require more control than this, you can specify each interface -individually:-
--
-
-@listen = (
- ["gb7baa.dxcluster.net", 8000],
- ["44.131.16.2", 6300],
-);
-
-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.
- -Restart the cluster.pl program to enable the listener.
- -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.
- -AGW Engine is a Windows based ax25 stack. You can connect to an AGW engine -from Linux as well as Windows based machines.
- -In order to enable access to an AGW Engine you need to copy -/spider/perl/AGWConnect.pm to /spider/local and edit it. -Specifically you must:-
--
$enable to 1.$login and $passwd to the values set up in your AGW installation.
-If you haven't set any there, then you should not touch these values.$addr
-and $port appropriately.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. -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, cd to spider/src and issue the command ...
--
-
-./client gb7baa (using the callsign you set as a node)
-
-You should get an initialisation string from DXSpider like this ...
--
-
-./client gb7baa
-PC38^GB7MBC^~
-
-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.
- -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:
--
-
-unset/node gb7baa
-
-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.
- -The connect scripts consist of lines which start with the following keywords -or symbols:-
--
All lines starting with a # are ignored, as are completely
-blank lines.
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 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 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!
' 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 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]).
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.
--
-
-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
-
--
-
-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
-
--
-
-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
-
-Both these examples assume that everything is set up properly at the other end. -You will find other examples in the /spider/examples directory.
- -You start the connection, from within a sysop enabled cluster login, by typing -in the word connect followed by a script name like this ....
--
-
-G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
-connection to GB7DJK-1 started
-G0VGS de GB7MBC 13-Dec-1998 2043Z >
-
-This will start a connection using the script called gb7djk-1. You can
-follow the connection by watching the term or console from where you started
-cluster.pl. From version 1.47 onwards, you will need to set/debug connect first.
-You should see something like this ...
-
-
-<- 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
-
-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 -before 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 ...
--
-
-'connect' ''
-
-In a script, this might look like ...
--
-
-timeout 35
-abort (Busy|Sorry|Fail)
-connect telnet mary 3000
-'ogin:' 'gb7mbc'
-'>' 'telnet 44.131.93.96 7305'
-'connect' ''
-
-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.
- -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.
- -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 ...
--
-
-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' ''
-
-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.
- - -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.
- -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.
- -Login as root and bring up the /etc/inittab file in your favourite editor. Add -the following lines to the file near the end ...
--
-
-##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
-
-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 ...
--
-
-DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
-
-The line required for Slackware distributions is slightly different. My thanks to -Aurelio, PA3EZL for this information.
--
-
-DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
-
-This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart -it should it crash for any reason.
- -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.
- -As root type the command telinit q. DXSpider should start up -immediately. You will see the output on tty7 and if you login as sysop -you should find everything running nicely.
- -