X-Git-Url: http://gb7djk.dxcluster.net/gitweb/gitweb.cgi?a=blobdiff_plain;f=sgml%2Fadminmanual.sgml;h=39ec64313b937908ad8d4ef2e42b24baf9191516;hb=888f29019bd55b89ee5c506ee7d2d71f0c3dafb8;hp=d7bae3d5e0dbfaacf1df9a505ff47069c07fab6a;hpb=175151ba8f0fec2628e157c1d54dcbf89091e522;p=spider.git diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml index d7bae3d5..39ec6431 100644 --- a/sgml/adminmanual.sgml +++ b/sgml/adminmanual.sgml @@ -4,9 +4,10 @@ -
-This section describes the installation of DX Spider v1.35 on a
-
I am assuming a general knowledge of Linux and its commands. You should
@@ -34,26 +35,20 @@ know how to use tar and how to edit files using your favourite editor.
The crucial ingredient for all of this is
- In addition to the standard Red Hat distribution you will require the
-following
I will assume that you have already downloaded the latest tarball of
the DXSpider software and are ready to install it. I am assuming version
-1.35 for this section but of course you would use the latest version.
+1.46 for this section but of course you would use the latest version.
Login as root and create a user to run the cluster under.
-DON'T alter the DXVars.pm (or any other file) in /spider/perl, they are
-overwritten with every release. Any files or commands you place in /spider/local
-or /spider/local_cmd will automagically be used in preference to the ones in
-/spider/perl EVEN while the cluster is running!
+DON'T alter any file in /spider/perl, they are overwritten with every
+release. Any files or commands you place in /spider/local or /spider/local_cmd
+will automagically be used in preference to the ones in /spider/perl EVEN
+while the cluster is running!
Save the new file and change directory to ../perl ....
@@ -197,7 +192,7 @@ Now type the following command which creates the basic user file with you as
the sysop.
If all is well then login on another term or console as sysop and
-cd to /spider/perl. Now issue the following command ...
+cd to /spider/src. Now issue the following command ...
@@ -248,7 +243,7 @@ shutdown
and both the cluster and the client should return to Linux prompts.
-
In earlier versions of Spider, all the processes were Perl scripts. This
@@ -259,6 +254,61 @@ has to be "made". CD to /spider/src and type make. You
should see the output on your screen and hopefully now have a small C program
called client. Leave it in this directory.
+
+
+This section is designed for experienced Spider sysops who want to install
+Spider from scratch. It is simply a check list of things that need to be
+done without any explanations. The name in brackets at the end of each line
+is the user that should be doing that process.
+
+
+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 ....
@@ -290,7 +361,6 @@ spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
-This needs to be added above the standard services such as ftp, telnet etc.
Once this is done, you need to restart inetd like this ....
Now login as sysop and cd spider/perl. You can test that spider
+ Now login as sysop and cd spider/src. You can test that spider
is accepting telnet logins by issuing the following command ....
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:-
+
+
+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 &dquot;0.0.0.0&dquot;
+and select the correct port to listen on. So that it looks like this:-
+
+
+As standard, the listener will listen on all interfaces simultaneously.
+If you require more control than this, you can specify each interface
+individually:-
+
+
+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:-
+
+
@@ -346,7 +494,7 @@ 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.pl.
+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 ...
@@ -360,17 +508,17 @@ The case does not matter as long as you have a version of DXSpider later than
That is now set, it is as simple as that. To prove it, login on yet another
-console as sysop and issue the command ...
+console as sysop, cd to spider/src and issue the command ...
You should get an initialisation string from DXSpider like this ...
+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:
+
+
@@ -390,20 +547,20 @@ Writing a script for connections is therefore relatively simple.
The connect scripts consist of lines which start with the following keywords
or symbols:-
-
+
+
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 8000, this negotiation does
+If the connection is to a different port, such as 7300, this negotiation does
not happen and therefore no echo should be present.
@@ -601,6 +774,22 @@ the following lines to the file near the end ...
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 ...
+
+
This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart
it should it crash for any reason.
@@ -624,7 +813,7 @@ a comment)
# check every 10 minutes to see if gb7xxx is connected and if not
# start a connect job going
-0,10,20,30,40,50 * * * * start_connect('gb7xxx') if !connected('gb7xxx')
+0,10,20,30,40,50 * * * * start_connect('gb7xxx') if unless connected('gb7xxx')
@@ -1669,13 +1858,13 @@ You can also store other information in this directory, either directly or
nested under directories. One use for this would be to store DX bulletins
such as the OPDX bulletins. These can be listed and read by the user.
To keep things tidy, make a directory under /spider/packclus called
-bulletins. Now copy any OPDX or similar bulletins into it. These
+bulletin. Now copy any OPDX or similar bulletins into it. These
can be listed by the user in the same way as above using the show/files
-command with an extension for the bulletins directory you have just created,
+command with an extension for the bulletin directory you have just created,
like this ....
@@ -1683,11 +1872,11 @@ An example would look like this ....
In later versions of Spider a simple console program is provided for the sysop.
This has a type ahead buffer with line editing facilities and colour for spots,
-announces etc. To use this program, simply use console.pl instead of client.pl.
+announces etc. To use this program, simply use console.pl instead of client.
To edit the colours, copy /spider/perl/Console.pl to /spider/local and edit the
@@ -1928,6 +2117,16 @@ load/keps
That is it! the kepler data has been updated.
+
+The command sh/qrz will only work once you have followed a few
+simple steps. First you need to get a user ID and password from qrz.com.
+Simply go to the site and create one. Secondly you need to copy the file
+/spider/perl/Internet.pm to /spider/local and alter it to match your user
+ID and password. You also at this point need to set $allow=1 to complete
+the setup. Many thanks to Fred Lloyd, the proprieter of
+
-You can remove this level with unset/debug <name>
+You can choose to log several different levels. The levels are
+
+chan
+state
+msg
+cron
+connect
+
+You can show what levels you are logging with the show/debug
+command.
+
+You can remove a debug level with unset/debug <name>
-
Display all the bad spotter's callsigns in the system, see SET/BADSPOTTER
for more information.
+
+
+
+This command allows you to see all the users that can be seen
+and the nodes to which they are connected. With the optional node,
+you can specify a particular node to look at.
+
+This command is normally abbreviated to: sh/c
+
+BE WARNED: the list that is returned can be VERY long
+
+
+
+
+Show all the nodes connected locally and the nodes they have connected.
+
+
+
+
+This command shows information on all the active connections known to
+the node. This command gives slightly more information than WHO.
+
@@ -3987,6 +4234,16 @@ time and UTC as the computer has it right now. If you give some prefixes
then it will show UTC and UTC + the local offset (not including DST) at
the prefixes or callsigns that you specify.
+
+
+
+The levels can be set with set/debug
+