X-Git-Url: http://scm.dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=sgml%2Fadminmanual.sgml;h=cc6ba498f7cdbbc2030356d223cf5dcfbc2eb031;hb=8a43bfdeacbbc78d0ff70df35528f78be39e7485;hp=effa0d275391c4d422b699622d246426c874a9d9;hpb=94cb29696634f8ecfef5595e55f1961049f6a4e3;p=spider.git diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml index effa0d27..cc6ba498 100644 --- a/sgml/adminmanual.sgml +++ b/sgml/adminmanual.sgml @@ -4,1004 +4,141 @@ -
-This section describes the installation of DX Spider v1.46 on a
-
-I am assuming a general knowledge of Linux and its commands. You should
-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 modules from
-
-
-Do get the latest versions of these packages and install them
-but use the above list as the earliest versions usable.
-
-
-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.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.
-
-Now set a password for the user ...
-
-
-Now to unpack the DX Spider distribution, set symbolic links and group
-permissions. Copy the tarball to /home/sysop and do the following.
-
-
-The next step is to set the permissions on the Spider directory tree and files ....
-
-
-This last step allows various users of the group spider to have
-write access to all the directories. This is not really needed just yet
-but will be useful when web interfaces start to appear.
-
-
-Finally, you need to fix the permissions on the ax25_call and netrom_call
-programs. Check where they are with the locate command and alter
-the permissions with the chmod command like this ..
-
-
-Now login to your machine as the user you created earlier. In my case that
-user is called sysop. Once logged in, issue the following commands ....
-
-
-Using the distributed DXVars.pm as a a template, set your cluster callsign,
-sysop callsign and other user info to suit your own environment. Note that
-this a perl file which will be parsed and executed as part of the cluster. If
-you get it wrong then perl will complain when you start the cluster process.
-It is important only to alter the text of any section. Some of the lines look
-a little odd. Take this line for example ....
-
-
-$myemail = "ianmaude\@btinternet.com";
-
-
-
-There appears to be an extra slash in there. However this has to be there
-for the file to work so leave it in.
-
-
-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 ....
-
-
-Now type the following command which creates the basic user file with you as
-the sysop.
-
-
-We can now bring spider up for the first time and see if all is well or not!
-It should look something like this ...
-
-
-If all is well then login on another term or console as sysop and
-cd to /spider/perl. Now issue the following command ...
-
-
-This should log you into the cluster as the sysop under the alias callsign we
-set earlier. In this case the callsign is G0VGS. The cluster callsign is set
-in the DXVars.pm file in /spider/local. In this case we will assume that this
-was set as GB7MBC. You should therefore see this when you login ....
-
-
-and both the cluster and the client should return to Linux prompts.
-
-
-In earlier versions of Spider, all the processes were Perl scripts. This
-was fine but with a lot of users your computer memory would soon be used up.
-To combat this a new client was written in "C". This client only works for
-incoming connects at the moment. Before you can use it though it
-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.
-
-
-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 ...
-
-
-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 ....
-
-
-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
-is accepting telnet logins by issuing the following command ....
-
-
-Assuming all is well, then try a telnet from your linux console ....
-
-
-You should now get the login prompt and be able to login as before.
-
-
-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 ...
-
-
-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.
-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 ...
-
-
-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/perl and issue the command ...
-
-
-You should get an initialisation string from DXSpider like this ...
-
-
-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:-
-
-
-
-
-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 ....
-
-
-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
-
-In a script, this might look like ...
-
-
-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 8000, 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 ...
-
-
-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 and if
-connection scripts fail they have to be started again manually too, not much use
-if you are not at the console! So, in this section we will automate both.
-Firstly starting the cluster.
-
-
-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 ...
-
-
-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.
-
-
-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.
-
-
-So far so good, now to automate script connections...
-
-
-Login as sysop and create a file in /spider/local_cmd called crontab.
-Edit it with your favourite editor and add a line like this (I have included
-a comment)
-
-
-The callsign involved will be the callsign of the cluster node you are
-going to connect to. This will now check every 10 minutes to see if
-gb7xxx is connected, if it is then nothing will be done. If it is not,
-then a connect attempt will be started.
-
-
-There are probably lots of other things you could use this crontab file for.
-If you want to know more about it, look at the
-
-Starting with version 1.13 there is simple hop control available on a per
-node basis. Also it is possible to isolate a network completely so that you
-get all the benefits of being on that network, but can't pass on information
-from it to any other networks you may be connected to (or vice versa).
-
-
-In /spider/data you will find a file called hop_table.pl. This is the file
-that controls your hop count settings. It has a set of default hops on the
-various PC frames and also a set for each node you want to alter the hops for.
-You may be happy with the default settings of course, but this powerful tool
-can help to protect and improve the network. The file will look something
-like this ...
-
-
-Each set of hops is contained within a pair of curly braces and contains a
-series of PC frame types. PC11 for example is a DX spot. The figures here
-are not exhaustive but should give you a good idea of how the file works.
-
-
-You can alter this file at any time, including whilst the cluster is running.
-If you alter the file during runtime, the command load/hops will
-bring your changes into effect.
-
-
-It is possible to isolate networks from each other on a "gateway" node using the
- set/isolate <node_call> command.
-
-
-The effect of this is to partition an isolated network completely from another
-nodes connected to your node. Your node will appear on and otherwise behave
-normally on every network to which you are connected, but data from an isolated
-network will not cross onto any other network or vice versa. However all the
-spot, announce and WWV traffic and personal messages will still be handled
-locally (because you are a real node on all connected networks), that is locally
-connected users will appear on all networks and will be able to access and
-receive information from all networks transparently. All routed messages will
-be sent as normal, so if a user on one network knows that you are a gateway for
-another network, he can still still send a talk/announce etc message via your
-node and it will be routed across.
-
-
-The only limitation currently is that non-private messages cannot be passed down
-isolated links regardless of whether they are generated locally. This will change
-when the bulletin routing facility is added.
-
-
-If you use isolate on a node connection you will continue to receive all
-information from the isolated partner, however you will not pass any information
-back to the isolated node. There are times when you would like to forward only
-spots across a link (maybe during a contest for example). To do this, isolate
-the node in the normal way and put in a filter in the /spider/filter/spots
-directory to override the isolate. This filter can be very simple and consists
-of just one line ....
-
-
-There is a lot more on filtering in the next section.
-
-
-Filters can be set for spots, announcements and WWV. You will find the
-directories for these under /spider/filter. You will find some examples in
-the directories with the suffix .issue. There are two types of
-filter, one for incoming information and one for outgoing information.
-Outgoing filters are in the form CALLSIGN.pl and incoming filters
-are in the form in_CALLSIGN.pl. Filters can be set for both nodes
-and users.
-
-
-All filters work in basically the same way. There are several elements
-delimited by commas. There can be many lines in the filter and they are
-read from the top by the program. When writing a filter you need to think
-carefully about just what you want to achieve. You are either going to write
-a filter to accept or to reject. Think of a filter as
-having 2 main elements. For a reject filter, you would have a line or multiple
-lines rejecting the things you do not wish to receive and then a default line
-accepting everything else that is not included in the filter. Likewise, for an
-accept filter, you would have a line or multiple lines accepting the things you
-wish to receive and a default line rejecting everthing else.
-
-
-In the example below, a user requires a filter that would only return SSB spots
-posted in Europe on the HF bands. This is achieved by first rejecting the CW
-section of each HF band and rejecting all of VHF, UHF etc based on frequency.
-Secondly, a filter rule is set based on CQ zones to only accept spots posted in
-Europe. Lastly, a default filter rule is set to reject anything outside the filter.
-
-
-The actual elements of each filter are described more fully in the following
-sections.
+
-The elements of the Spot filter are ....
+
-
-There are 3 elements here to look at. Firstly, the action element. This is
-very simple and only 2 possible states exist, accept (1) or drop (0).
+
-The second element is the field_no. There are 13 possiblities to choose from
-here ....
-
-
-The third element tells us what to expect in the fourth element. There are
-4 possibilities ....
+This is achieved by using filtering on a route basis. There is a
+default setting to help to protect the network, especially useful for new
+and inexperienced SysOps. The idea is simple. When Spider is started
+for the first time and a connection is made to or from another node,
+the default is to only send the nodes you already have that are in your
+own zone. For example, in the UK the default setting would be to send
+only UK nodes to any connection. This can be filtered further (down to
+a single node if needed) or expanded as required.
-
-The fifth element is simply the hops to set in this filter. This would only
-be used if the filter was for a node of course and overrides the hop count in
-hop_table.pl.
+
-So, let's look at an example spot filter. It does not matter in the example
-who the filter is to be used for. So, what do we need in the filter? We need
-to filter the spots the user/node requires and also set a default rule for
-anything else outside the filter. Below is a simple filter that stops spots
-arriving from outside Europe.
-
-
-So the filter is wrapped in between a pair of square brackets. This tells
-Spider to look in between these limits. Then each line is contained within
-its own square brackets and ends with a comma. Lets look carefully at the first
-line. The first element is 0 (drop). Therefore anything we put on this line
-will not be accepted. The next element is 4. This means we are filtering by
-the spotter. The third element is the letter "a" which tells the program to
-expect an alphanumeric expression in the fourth element. The fourth element
-is a list of letters separated by the pipe symbol.
+It is possible to reset the default setting for node connections should
+you wish to do so, however this can be dangerous to the network unless
+you have some experience in how all this works.... be careful! It is
+also possible to change settings for one connection only. You can,
+therefore, have many different filters set dependent on the amount of
+node links you have.
-What this line does is tell the program to drop any spots posted by anyone in
-the USA, Canada or Japan.
+I should at this stage give a little bit of background on filters. All
+the filters in Spider work in basically the same way. You can either
+accept or reject various options in order to create the filter rules
+you wish to achieve. Some filters are user settable, others can only
+be altered by the sysop. Route filtering can only be done by the sysop.
-
-The second line is the default rule for anything else. The "d" tells us this
-and the line simply reads... accept anything else.
+
-You can add as many lines as you need to complete the filter but if there are
-several lines of the same type it is neater to enclose them all as one line.
-An example of this is where specific bands are set. We could write this like
-this ....
+As discussed previously, a default setting exists that only sends nodes
+from your own zone. This can be overridden by using the default_node
+filter option like this ...
-But the line below achieves the same thing and is more efficient ....
+where filter_option is one of the following ...
+Please be careful if you alter this setting, it will affect
+
+Exactly the same rules apply for general route filtering. You would
+use either an accept filter or a reject filter like this ...
+
-
-It should be noted that the filter will start to be used only once a user/node
-has logged out and back in again.
-
-I am not going to spend any more time on these filters now as they will become
-more "comprehensive" in the near future.
+Here are some examples of route filters ...
-
+In /spider/data you will find a file called hop_table.pl. This is the file
+that controls your hop count settings. It has a set of default hops on the
+various PC frames and also a set for each node you want to alter the hops for.
+You may be happy with the default settings of course, but this powerful tool
+can help to protect and improve the network. The file will look something
+like this ...
+
+
+Each set of hops is contained within a pair of curly braces and contains a
+series of PC frame types. PC11 for example is a DX spot. The figures here
+are not exhaustive but should give you a good idea of how the file works.
+
+
+You can alter this file at any time, including whilst the cluster is running.
+If you alter the file during runtime, the command load/hops will
+bring your changes into effect.
+
+
+It is possible to isolate networks from each other on a "gateway" node using the
+ set/isolate <node_call> command.
+
+
+The effect of this is to partition an isolated network completely from another
+node connected to your node. Your node will appear on and otherwise behave
+normally on every network to which you are connected, but data from an isolated
+network will not cross onto any other network or vice versa. However all the
+spot, announce and WWV traffic and personal messages will still be handled
+locally (because you are a real node on all connected networks), that is locally
+connected users will appear on all networks and will be able to access and
+receive information from all networks transparently. All routed messages will
+be sent as normal, so if a user on one network knows that you are a gateway for
+another network, he can still still send a talk/announce etc message via your
+node and it will be routed across.
+
+
+The only limitation currently is that non-private messages cannot be passed down
+isolated links regardless of whether they are generated locally. This will change
+when the bulletin routing facility is added.
+
+
+If you use isolate on a node connection you will continue to receive all
+information from the isolated partner, however you will not pass any information
+back to the isolated node. There are times when you would like to forward only
+spots across a link (maybe during a contest for example). To do this, isolate
+the node in the normal way and put in a filter in the /spider/filter/spots
+directory to override the isolate. This filter can be very simple and consists
+of just one line ....
+
+
@@ -1700,11 +947,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
@@ -2148,6 +1395,50 @@ default for nodes and users eg:-
accept/ann user_default by G,M,2
+
+
+Create an 'accept this routing PC Protocol' line for a filter.
+
+
+An accept filter line means that if a PC16/17/19/21/24/41/50 matches this filter
+it is passed thru that interface. See HELP FILTERING for more info. Please read this
+to understand how filters work - it will save a lot of grief later on.
+
+
+You can use any of the following things in this line:-
+
+
+some examples:-
+
+
+You can use the tag 'all' to accept everything eg:
+
+
@@ -2334,7 +1625,9 @@ default for nodes and users eg:-
Send an announcement to LOCAL users only, where <text> is the text
-of the announcement you wish to broadcast
+of the announcement you wish to broadcast. If you do not wish to receive
+announces, use the set/noannounce command. Any announces made by
+a sysop will override set/noannounce.
+
+
+Create an 'reject this routing PC Protocol' line for a filter.
+
+
+An reject filter line means that if a PC16/17/19/21/24/41/50 matches this filter
+it is NOT passed thru that interface. See HELP FILTERING for more info. Please
+read this to understand how filters work - it will save a lot of grief later on.
+You can use any of the following things in this line:-
+
+
+some examples:-
+
+
+You can use the tag 'all' to reject everything eg:
+
+
@@ -3523,6 +2857,13 @@ Use with extreme care. This command may well be superceded by FILTERing.
Add a beep to DX and other terminal messages.
+
+
+
@@ -4008,6 +3349,43 @@ for more information.
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.
+
@@ -4577,6 +3955,24 @@ Only the fields that are defined (in perl term) will be displayed.
This command shows the internal status of a message and includes information
such as to whom it has been forwarded, its size, origin etc etc.
+
+If no message number is given then the status of the message system is
+displayed.
+
+
+
+
+
+