html/installation-4.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
   2 <HTML>
   3 <HEAD>
   4  <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.16">
   5  <TITLE>The DXSpider Installation Manual v1.50: Configuration</TITLE>
   6  <LINK HREF="installation-5.html" REL=next>
   7  <LINK HREF="installation-3.html" REL=previous>
   8  <LINK HREF="installation.html#toc4" REL=contents>
   9 <link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
  10 </HEAD>
  11 <BODY>
  12 <A HREF="installation-5.html">Next</A>
  13 <A HREF="installation-3.html">Previous</A>
  14 <A HREF="installation.html#toc4">Contents</A>
  15 <HR>
  16 <H2><A NAME="s4">4.</A> <A HREF="installation.html#toc4">Configuration</A></H2>
  17
  18 <H2><A NAME="ss4.1">4.1</A> <A HREF="installation.html#toc4.1">Allowing ax25 connects from users</A>
  19 </H2>
  20
  21 <P>This is dealt with in the previous section</P>
  22
  23 <H2><A NAME="ss4.2">4.2</A> <A HREF="installation.html#toc4.2">Allowing telnet connects from users </A>
  24 </H2>
  25
  26 <P>
  27 >From version 1.47 there is a new (more efficient) way of doing this
  28 (see next section) but, if you prefer, the method of doing it described
  29 here will continue to work just fine.</P>
  30
  31 <P>Allowing telnet connections is quite simple.  Firstly you need to add a line
  32 in /etc/services to allow connections to a port number, like this ....</P>
  33 <P>
  34 <BLOCKQUOTE><CODE>
  35 <PRE>
  36 spdlogin   8000/tcp     # spider anonymous login port
  37 </PRE>
  38 </CODE></BLOCKQUOTE>
  39 </P>
  40
  41 <P>Then add a line in /etc/inetd.conf like this ....</P>
  42 <P>
  43 <BLOCKQUOTE><CODE>
  44 <PRE>
  45 spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
  46 </PRE>
  47 </CODE></BLOCKQUOTE>
  48 </P>
  49
  50 <P>Once this is done, you need to restart inetd like this ....</P>
  51 <P>
  52 <BLOCKQUOTE><CODE>
  53 <PRE>
  54 killall -HUP inetd
  55 </PRE>
  56 </CODE></BLOCKQUOTE>
  57 </P>
  58
  59 <P>Now login as <EM>sysop</EM> and cd spider/src. You can test that spider
  60 is accepting telnet logins by issuing the following command ....</P>
  61 <P>
  62 <BLOCKQUOTE><CODE>
  63 <PRE>
  64 ./client login telnet
  65 </PRE>
  66 </CODE></BLOCKQUOTE>
  67 </P>
  68
  69 <P>You should get a login prompt and on issuing a callsign, you will be given
  70 access to the cluster.  Note, you will not get a password login.  There seems
  71 no good reason for a password prompt to be given so it is not asked for.</P>
  72
  73 <P>Assuming all is well, then try a telnet from your linux console ....</P>
  74 <P>
  75 <BLOCKQUOTE><CODE>
  76 <PRE>
  77 telnet localhost 8000
  78 </PRE>
  79 </CODE></BLOCKQUOTE>
  80 </P>
  81
  82 <P>You should now get the login prompt and be able to login as before.</P>
  83
  84 <H2><A NAME="ss4.3">4.3</A> <A HREF="installation.html#toc4.3">Setting up telnet connects (from 1.47 onwards)</A>
  85 </H2>
  86
  87 <P>>From version 1.47 you can choose to allow the perl cluster.pl program to
  88 allow connections directly (i.e. not via the <CODE>/spider/src/client</CODE>
  89 interface program). If you are using Windows then this is the only method
  90 available of allowing incoming telnet connections.</P>
  91
  92 <P>To do this you need first to remove any line that you may previously have set
  93 up in /etc/inetd.conf. Remember to:-</P>
  94 <P>
  95 <BLOCKQUOTE><CODE>
  96 <PRE>
  97 killall -HUP inetd
  98 </PRE>
  99 </CODE></BLOCKQUOTE>
 100 </P>
 101
 102 <P>to make the change happen...</P>
 103
 104 <P>Having done that, you need to copy the file
 105 <EM>/spider/perl/Listeners.pm</EM> to <EM>/spider/local</EM> and
 106 then edit it. You will need to uncomment the line containing &quot;0.0.0.0&quot;
 107 and select the correct port to listen on. So that it looks like this:-</P>
 108 <P>
 109 <BLOCKQUOTE><CODE>
 110 <PRE>
 111 @listen = (
 112     ["0.0.0.0", 8000],
 113 );
 114 </PRE>
 115 </CODE></BLOCKQUOTE>
 116 </P>
 117
 118 <P>As standard, the listener will listen on all interfaces simultaneously.
 119 If you require more control than this, you can specify each interface
 120 individually:-</P>
 121 <P>
 122 <BLOCKQUOTE><CODE>
 123 <PRE>
 124 @listen = (
 125     ["gb7baa.dxcluster.net", 8000],
 126     ["44.131.16.2", 6300],
 127 );
 128 </PRE>
 129 </CODE></BLOCKQUOTE>
 130 </P>
 131
 132 <P>This will only be successful if the IP addresses on each interface are static.
 133 If you are using some kind of dynamic IP addressing then the 'default' method
 134 is the only one that will work.</P>
 135
 136 <P>Restart the cluster.pl program to enable the listener.</P>
 137
 138 <P>One important difference with the internal listener is that no echoing
 139 is done by the cluster program. Users will need to set 'local-echo' on in
 140 their telnet clients if it isn't set automatically (as per the standards).
 141 Needless to say this will probably only apply to Windows users. </P>
 142
 143 <H2><A NAME="ss4.4">4.4</A> <A HREF="installation.html#toc4.4">Setting up for AGW Engine (1.47 onwards)</A>
 144 </H2>
 145
 146 <P>AGW Engine is a Windows based ax25 stack. You can connect to an AGW engine
 147 from Linux as well as Windows based machines.</P>
 148
 149 <P>In order to enable access to an AGW Engine you need to copy
 150 <EM>/spider/perl/AGWConnect.pm</EM> to <EM>/spider/local</EM> and edit it.
 151 Specifically you must:-</P>
 152 <P>
 153 <UL>
 154 <LI> set <CODE>$enable</CODE> to 1.</LI>
 155 <LI> set <CODE>$login</CODE> and <CODE>$passwd</CODE> to the values set up in your AGW installation.
 156 If you haven't set any there, then you should not touch these values.</LI>
 157 <LI> You can connect to a remote AGW engine (ie on some other machine) by changing <CODE>$addr</CODE>
 158 and <CODE>$port</CODE> appropriately.</LI>
 159 <LI> Restart the cluster.pl program</LI>
 160 </UL>
 161    </P>
 162
 163
 164 <H2><A NAME="ss4.5">4.5</A> <A HREF="installation.html#toc4.5">Setting up node connects</A>
 165 </H2>
 166
 167 <P>In order to allow cluster node connections, spider needs to know that the
 168 connecting callsign is a cluster node.  This is the case whether the connect
 169 is incoming or outgoing.  In spider this is a simple task and can be done in
 170 runtime.</P>
 171
 172 <P>Later versions of Spider can distinguish different software and treat them
 173 differently.  For example, the WCY beacon cannot be handles by AK1A type
 174 nodes as AK1A does not know what to do with PC73.  There are 4 different
 175 types of node at present and although they may not have any major
 176 differences at the moment, it allows for compatibility.  The 4 types are ...</P>
 177 <P>
 178 <BLOCKQUOTE><CODE>
 179 <PRE>
 180 set/node        (AK1A type)
 181 set/spider
 182 set/dxnet
 183 set/clx
 184 </PRE>
 185 </CODE></BLOCKQUOTE>
 186 </P>
 187
 188 <P>For now, we will assume that the cluster we are going to connect to is an
 189 AK1A type node.</P>
 190
 191 <P>Start up the cluster as you did before and login as the sysop with client.
 192 The cluster node I am wanting to make a connection to is GB7BAA but you would
 193 obviously use whatever callsign you required.  At the prompt type ...</P>
 194 <P>
 195 <BLOCKQUOTE><CODE>
 196 <PRE>
 197 set/node gb7baa
 198 </PRE>
 199 </CODE></BLOCKQUOTE>
 200 </P>
 201
 202 <P>The case does not matter as long as you have a version of DXSpider later than
 203 1.33.  Earlier versions required the callsign to be in upper case.</P>
 204
 205 <P>That is now set, it is as simple as that.  To prove it, login on yet another
 206 console as sysop, cd to spider/src and issue the command ...</P>
 207 <P>
 208 <BLOCKQUOTE><CODE>
 209 <PRE>
 210 ./client gb7baa (using the callsign you set as a node)
 211 </PRE>
 212 </CODE></BLOCKQUOTE>
 213 </P>
 214
 215 <P>You should get an initialisation string from DXSpider like this ...</P>
 216 <P>
 217 <BLOCKQUOTE><CODE>
 218 <PRE>
 219 ./client gb7baa
 220 PC38^GB7MBC^~
 221 </PRE>
 222 </CODE></BLOCKQUOTE>
 223 </P>
 224 <P>If the callsign you just set up as a cluster node is for an incoming connect,
 225 this is all that needs to be done.  If the connection is to be outgoing then
 226 a connection script needs to be written.</P>
 227
 228 <P>Sometimes you make a mistake... Honest, it does happen.  If you want to make a node
 229 back to being a normal user, regardless
 230 of what type it is, do:</P>
 231 <P>
 232 <BLOCKQUOTE><CODE>
 233 <PRE>
 234 unset/node gb7baa
 235 </PRE>
 236 </CODE></BLOCKQUOTE>
 237 </P>
 238
 239 <H2><A NAME="ss4.6">4.6</A> <A HREF="installation.html#toc4.6">Connection scripts</A>
 240 </H2>
 241
 242 <P>Because DXSpider operates under Linux, connections can be made using just about
 243 any protocol;  AX25, NETRom, tcp/ip, ROSE etc are all possible examples.
 244 Connect scripts live in the /spider/connect directory and are simple ascii files.
 245 Writing a script for connections is therefore relatively simple.  </P>
 246
 247 <P>The connect scripts consist of lines which start with the following keywords
 248 or symbols:-</P>
 249 <P>
 250 <DL>
 251
 252 <DT><B>#</B><DD><P>All lines starting with a <CODE>#</CODE> are ignored, as are completely
 253 blank lines.</P>
 254
 255 <DT><B>timeout</B><DD><P><CODE>timeout</CODE> followed by a number is the number of seconds to wait for a
 256 command to complete. If there is no timeout specified in the script
 257 then the default is 60 seconds.</P>
 258
 259 <DT><B>abort</B><DD><P><CODE>abort</CODE> is a regular expression containing one or more strings to look
 260 for to abort a connection. This is a perl regular expression and is
 261 executed ignoring case.</P>
 262
 263 <DT><B>connect</B><DD><P><CODE>connect</CODE> followed by ax25, agw (for Windows users) or telnet and some type dependent
 264 information. In the case of a telnet connection, there can be up to
 265 two parameters.
 266 The first is the ip address or hostname of the computer you wish to
 267 connect to and the second is the port number you want to use (this
 268 can be left out if it is a normal telnet session).
 269 In the case of an ax25 session then this would normally be a call to
 270 ax25_call or netrom_call as in the example above. It is your
 271 responsibility to get your node and other ax25 parameters to work
 272 before going down this route!</P>
 273
 274 <DT><B>'</B><DD><P><CODE>'</CODE> is the delimiting character for a word or phrase of an expect/send
 275 line in a chat type script. The words/phrases normally come in pairs,
 276 either can be empty. Each line reads input from the connection until
 277 it sees the string (or perl regular expression) contained in the
 278 left hand string. If the left hand string is empty then it doesn't
 279 read or wait for anything. The comparison is done ignoring case.
 280 When the left hand string has found what it is looking for (if it is)
 281 then the right hand string is sent to the connection.
 282 This process is repeated for every line of chat script. </P>
 283
 284 <DT><B>client</B><DD><P><CODE>client</CODE> starts the connection, put the arguments you would want here
 285 if you were starting the client program manually. You only need this
 286 if the script has a different name to the callsign you are trying to
 287 connect to (i.e. you have a script called other which actually
 288 connects to GB7DJK-1 [instead of a script called gb7djk-1]).</P>
 289 </DL>
 290 </P>
 291
 292 <P>There are many possible ways to configure the script but here are three examples,
 293 one for a NETRom/AX25 connect, one for AGW engines and one for tcp/ip.  </P>
 294 <P>
 295 <BLOCKQUOTE><CODE>
 296 <PRE>
 297 timeout 60
 298 abort (Busy|Sorry|Fail)
 299 # don't forget to chmod 4775 netrom_call!
 300 connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh
 301 'Connect' ''
 302 'Connect' 'c np7'
 303 'Connect' 'c gb7dxm'
 304 # you can leave this out if you call the script 'gb7dxm'
 305 client gb7dxm ax25
 306 </PRE>
 307 </CODE></BLOCKQUOTE>
 308 </P>
 309
 310
 311 <P>
 312 <BLOCKQUOTE><CODE>
 313 <PRE>
 314 timeout 60
 315 abort (Busy|Sorry|Fail)
 316 # this does exactly the same as the previous example
 317 # the '1' is the AGW port number to connect thru for g1tlh
 318 connect agw 1 g1tlh
 319 'Connect' ''
 320 'Connect' 'c np7'
 321 'Connect' 'c gb7dxm'
 322 # you can leave this out if you call the script 'gb7dxm'
 323 client gb7dxm ax25
 324 </PRE>
 325 </CODE></BLOCKQUOTE>
 326 </P>
 327
 328
 329 <P>
 330 <BLOCKQUOTE><CODE>
 331 <PRE>
 332 timeout 15
 333 connect telnet dirkl.tobit.co.uk
 334 'login' 'gb7djk'
 335 'word' 'gb7djk'
 336 # tell GB7DJK-1 that it is connected to GB7DJK
 337 # you can leave this out if you call this script 'gb7djk'
 338 client gb7djk telnet
 339 </PRE>
 340 </CODE></BLOCKQUOTE>
 341 </P>
 342
 343 <P>Both these examples assume that everything is set up properly at the other end.
 344 You will find other examples in the /spider/examples directory.</P>
 345
 346 <H2><A NAME="ss4.7">4.7</A> <A HREF="installation.html#toc4.7">Starting the connection</A>
 347 </H2>
 348
 349 <P>You start the connection, from within a sysop enabled cluster login, by typing
 350 in the word <EM>connect</EM> followed by a script name like this ....</P>
 351 <P>
 352 <BLOCKQUOTE><CODE>
 353 <PRE>
 354 G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
 355 connection to GB7DJK-1 started
 356 G0VGS de GB7MBC 13-Dec-1998 2043Z >
 357 </PRE>
 358 </CODE></BLOCKQUOTE>
 359 </P>
 360
 361 <P>This will start a connection using the script called <EM>gb7djk-1</EM>.  You can
 362 follow the connection by watching the term or console from where you started
 363 <EM>cluster.pl</EM>.  From version 1.47 onwards, you will need to <CODE>set/debug connect</CODE> first.
 364 You should see something like this ...</P>
 365 <P>
 366 <BLOCKQUOTE><CODE>
 367 <PRE>
 368 &lt;- D G1TLH connect gb7djk-1
 369 -> D G1TLH connection to GB7DJK-1 started
 370 -> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
 371 timeout set to 15
 372 CONNECT sort: telnet command: dirkl.tobit.co.uk
 373 CHAT "login" -> "gb7djk"
 374 received "
 375 Red Hat Linux release 5.1 (Manhattan)
 376 Kernel 2.0.35 on an i586
 377 "
 378 received "login: "
 379 sent "gb7djk"
 380 CHAT "word" -> "gb7djk"
 381 received "gb7djk"
 382 received "Password: "
 383 sent "gb7djk"
 384 Connected to GB7DJK-1, starting normal protocol
 385 &lt;- O GB7DJK-1 telnet
 386 -> B GB7DJK-1 0
 387 GB7DJK-1 channel func  state 0 -> init
 388 &lt;- D GB7DJK-1
 389 &lt;- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
 390 &lt;- D GB7DJK-1 PC38^GB7DJK-1^~
 391 &lt;- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users  Max users 0  Uptime
 392 0 00:00^5447^~
 393     etc
 394 </PRE>
 395 </CODE></BLOCKQUOTE>
 396 </P>
 397
 398 <P>With later versions of Spider there is a set/login command for users.  This
 399 tells them when a user or node logs in or out.  If you do not add a line to
 400 your scripts after the final line (or before the client line which should always
 401 be last if needed) then the login/logout information will be sent to users
 402 <I>before</I> the login actually completes.  This means if a node is
 403 unreachable, it will continue sending logins and logouts to users even though it
 404 is not actually connecting.  To avoid this use the following line ...</P>
 405 <P>
 406 <BLOCKQUOTE><CODE>
 407 <PRE>
 408 'connect' ''
 409 </PRE>
 410 </CODE></BLOCKQUOTE>
 411 </P>
 412
 413 <P>In a script, this might look like ...</P>
 414 <P>
 415 <BLOCKQUOTE><CODE>
 416 <PRE>
 417 timeout 35
 418 abort (Busy|Sorry|Fail)
 419 connect telnet mary 3000
 420 'ogin:' 'gb7mbc'
 421 '>' 'telnet 44.131.93.96 7305'
 422 'connect' ''
 423 </PRE>
 424 </CODE></BLOCKQUOTE>
 425 </P>
 426
 427 <H2><A NAME="ss4.8">4.8</A> <A HREF="installation.html#toc4.8">Telnet echo</A>
 428 </H2>
 429
 430 <P>Cluster links in particular suffer greatly from the presence of telnet echo.
 431 This is caused by the telnet negotiation itself and can create at worst severe
 432 loops.  At best it creates unnecessary bandwidth and large logfiles!  There are
 433 things that can be done to limit this problem but will not always work dependent
 434 on the route taken to connect.</P>
 435
 436 <P>Telnet echo itself should only be a problem if the connection is being made to
 437 the telnet port (23).  This port uses special rules that include echo negotiation.
 438 If the connection is to a different port, such as 7300, this negotiation does
 439 not happen and therefore no echo should be present.</P>
 440
 441 <P>Sometimes it is not possible to make a direct connection to another node and this
 442 can cause problems.  There is a way of trying to suppress the telnet echo but
 443 this will not always work, unfortunately it is difficult to be more specific.
 444 Here is an example of what I mean ...</P>
 445 <P>
 446 <BLOCKQUOTE><CODE>
 447 <PRE>
 448 timeout 35
 449 abort (Busy|Sorry|Fail)
 450 connect telnet mary.lancs.ac.uk
 451 'ogin:' 'gb7mbc'
 452 'word:' 'mypasswd'
 453 '\$' 'stty -echo raw'
 454 '\$' 'telnet 44.131.93.96'
 455 'connect' ''
 456 </PRE>
 457 </CODE></BLOCKQUOTE>
 458 </P>
 459
 460 <P>So, the first connection is made by Spider.  This is fine as Spider uses the
 461 Net_Telnet script from within perl.  This actually uses TCP rather than TELNET
 462 so no negotiation will be done on the first connection.  Once connected to
 463 mary.lancs.ac.uk, the command is sent to suppress echo.  Now a telnet is made
 464 to a cluster node that is accepting connections on port 23.  The problem with
 465 this link is that the negotiation is made by the remote machine, therefore you
 466 have no control over it.  The chances are that this link will create echo and
 467 there will be no way you can stop it.</P>
 468
 469
 470 <H2><A NAME="ss4.9">4.9</A> <A HREF="installation.html#toc4.9">Autostarting the cluster</A>
 471 </H2>
 472
 473 <P>Ok, you should now have DXSpider running nicely and allowing connects by cluster
 474 nodes or users.  However, it has to be shutdown and restarted manually.  It
 475 would be much easier to have it start automatically. </P>
 476
 477 <P>This is not only a way to start the cluster automatically, it also works as a
 478 watchdog, checking the sanity of DXSpider and respawning it should it crash for
 479 any reason.  Before doing the following, shutdown the cluster as you did earlier.</P>
 480
 481 <P>Login as root and bring up the /etc/inittab file in your favourite editor.  Add
 482 the following lines to the file near the end ...</P>
 483 <P>
 484 <BLOCKQUOTE><CODE>
 485 <PRE>
 486 ##Start DXSpider on bootup and respawn it should it crash
 487 DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
 488 </PRE>
 489 </CODE></BLOCKQUOTE>
 490 </P>
 491
 492 <P>This line works fine for RedHat distributions. It is also fine for SuSE up to
 493 7.0.  From SuSE 7.1 you need to add runlevels 2 and 5 like this ...</P>
 494 <P>
 495 <BLOCKQUOTE><CODE>
 496 <PRE>
 497 DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
 498 </PRE>
 499 </CODE></BLOCKQUOTE>
 500 </P>
 501
 502 <P>The line required for Slackware distributions is slightly different.  My thanks to
 503 Aurelio, PA3EZL for this information.</P>
 504 <P>
 505 <BLOCKQUOTE><CODE>
 506 <PRE>
 507 DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
 508 </PRE>
 509 </CODE></BLOCKQUOTE>
 510 </P>
 511
 512 <P>This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart
 513 it should it crash for any reason.</P>
 514
 515 <P>NB: It should be noted that /dev/tty7 is only an example.  Some SuSE systems will
 516 only accept upto tty6.  It really does not matter which tty you run it on.</P>
 517
 518 <P>As root type the command <EM>telinit q</EM>.  DXSpider should start up
 519 immediately.  You will see the output on tty7 and if you login as <EM>sysop</EM>
 520 you should find everything running nicely.</P>
 521
 522 <HR>
 523 <A HREF="installation-5.html">Next</A>
 524 <A HREF="installation-3.html">Previous</A>
 525 <A HREF="installation.html#toc4">Contents</A>
 526 </BODY>
 527 </HTML>