-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/src. 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.
-
-
-
-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.
-
-
-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 ...
-
-
-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 ....
-
-
-Once this is done, you need to restart inetd like this ....
-
- Now login as sysop and cd spider/src. 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.
-
-
-From version 1.47 you can chose to allow the perl cluster.pl program to
-allow connections direct (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.
+The new functionality introduced in version 1.48 is filtering the node
+and user protocol frames on a "per interface" basis. We call this
+
-To do this you need first to remove any line that you may previously have set
-up in /etc/inetd.conf. Remember to:-
+
+What this really means is that you can control more or less completely
+which PC protocol frames, to do with user and node management, pass to
+each of your partner nodes. You can also limit what comes into your
+node from your partners. You can even control the settings that your
+partner node has for the routing information that it sends to you
+(using the
-to make the change happen...
+Initially when route filters were being tested we generated a
+"default" filter. Unfortunately it quickly became apparent that this
+might suit the UK cluster network but didn't really fit anybody else.
+However using a default filter is an appropriate thing to do. How, is
+explained further on.
-Having done that then 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 simultaniously. 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 which 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:-
-
-
-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.
-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/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:
-
-
-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 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 ...
-
-
-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.
-
-
+You will only require this functionality if you are
+"well-connected". What that means is that you are connected to several
+different parts of (say) the EU cluster and, at the same time, also
+connected to two or three places in the US which, in turn are
+connected back to the EU. This is called a "loop" and if you are
+seriously looped then you need filtering.
-The actual elements of each filter are described more fully in the following
-sections.
-
-
-The elements of the Spot filter are ....
+
+Anyway, without further discouragement, let me start the process
+of explanation.
-
-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).
+All normal systems should have a default routing filter and it should
+usually be set to send only the normal, unlooped, view of your
+"national" network. Here in the UK that means nodes from the UK and
+Eire, in EU it is more complex as the networks there grew up in a more
+intertwined way.
-
-The second element is the field_no. There are 13 possiblities to choose from
-here ....
+
+The generic commands are:-
-The third element tells us what to expect in the fourth element. There are
-4 possibilities ....
+where filter_option is one of the following ...
-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.
+Please be careful if you alter this setting, it will affect
+
-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.
+
+For the default routing filter then you have two real choices: either
+a "national" view or the "safe" option of only your own
+callsign. Examples of each (for my node: GB7DJK) are:-
-
-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.
-
-
-What this line does is tell the program to drop any spots posted by anyone in
-the USA, Canada or Japan.
+GB7DJK uses the first of these. The DXCC countries can be obtained from the
+
-The second line is the default rule for anything else. The "d" tells us this
-and the line simply reads... accept anything else.
+
+The example filters shown control
-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 ....
+
+It is also possible to control the
-But the line below achieves the same thing and is more efficient ....
+What this does is accept node and user information for our national
+network from nodes that are in our national network, but rejects such
+information from anyone else. Although it doesn't explicitly say so,
+by implication, any other node information (not from the UK and Eire)
+is accepted.
+
+
+As I imagine it will take a little while to get one's head around all of this you
+can study the effect of any rules that you try by watching the debug output
+after having done:-
+Exactly the same rules apply for general route filtering. You would
+use either an accept filter or a reject filter like this ...
+
+Here are some examples of route filters ...
+
-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.
+This last example takes everything except UK and Eire from PI4EHV-8
+but only sends him my local configuration (just a PC19 for GB7DJK and
+PC16s for my local users).
+
+
+It is possible to do
-In general terms you can create a 'reject' or an 'accept' filter which can have
+In general terms you can create a "reject" or an "accept" filter which can have
up to 10 lines in it. You do this using, for example ...
+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 ....
+
+
+
+
+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:
+
+
@@ -2498,7 +1712,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:
+
+
@@ -3687,6 +2944,13 @@ Use with extreme care. This command may well be superceded by FILTERing.
Add a beep to DX and other terminal messages.
+
+
+
@@ -4172,6 +3436,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.
+
@@ -4741,6 +4042,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.
+
+
+
+
+
+