<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>The DXSpider Installation and Administration Manual : Hop control</TITLE>
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.16">
+ <TITLE>The DXSpider Administration Manual v1.50: Scripts</TITLE>
<LINK HREF="adminmanual-5.html" REL=next>
<LINK HREF="adminmanual-3.html" REL=previous>
<LINK HREF="adminmanual.html#toc4" REL=contents>
+<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
</HEAD>
<BODY>
<A HREF="adminmanual-5.html">Next</A>
<A HREF="adminmanual-3.html">Previous</A>
<A HREF="adminmanual.html#toc4">Contents</A>
<HR>
-<H2><A NAME="s4">4. Hop control</A></H2>
+<H2><A NAME="s4">4.</A> <A HREF="adminmanual.html#toc4">Scripts</A></H2>
-<P>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).
-<P>
-<H2><A NAME="ss4.1">4.1 Basic hop control</A>
-</H2>
+<P>From 1.48 onwards it will become increasingly possible to control DXSpider's
+operation with scripts of various kinds.</P>
-<P>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 ...
+<P>The directory /spider/scripts is where it all happens and is used for several
+things. Firstly it contains a file called startup that can be used to call
+in any changes to the cluster from the default settings on startup. This
+script is executed immediately after all initialisation of the node is done
+but before any connections are possible. Examples of this include how many
+spots it is possible to get with the sh/dx command, whether you want
+registration/passwords to be permanently on etc. An example file is shown
+below and is included in the distribution as startup.issue.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
-#
-# hop table construction
-#
-
-package DXProt;
-
-# default hopcount to use
-$def_hopcount = 5;
-
-# some variable hop counts based on message type
-%hopcount =
-
- 11 => 10,
- 16 => 10,
- 17 => 10,
- 19 => 10,
- 21 => 10,
-);
-
-
-# the per node hop control thingy
-
-
-%nodehops =
-
- GB7ADX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-
- GB7UDX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
- GB7BAA => {
- 11 => 5,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-};
+#
+# startup script example
+#
+# set maximum no of spots allowed to 100
+# set/var $Spot::maxspots = 100
+#
+# Set registration on
+# set/var $main::reqreg = 1
+#
+# Set passwords on
+# set/var $main::passwdreq = 1
+#
</PRE>
</CODE></BLOCKQUOTE>
-<P>
-<P>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.
-<P>
-<P>You can alter this file at any time, including whilst the cluster is running. If you alter the file during runtime, the command <EM>load/hops</EM> will bring your changes into effect.
-<P>
-<H2><A NAME="ss4.2">4.2 Isolating networks</A>
-</H2>
+</P>
-<P>It is possible to isolate networks from each other on a "gateway" node using the
-<EM>set/isolate <node_call></EM> command.
-<P>
-<P>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.
-<P>
-<P>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.
-<P>
-<P>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 ....
+<P>As usual, any text behind a # is treated as a comment and not read. To use
+this file, simply rename it from startup.issue to startup. In our example
+above there are three options. The first option is the amount of spots that
+a user can request with the <EM>sh/dx</EM> command. Normally the default is
+to give 10 spots unless the user specifies more. Without this line enabled,
+the maximum a user can request is 100 spots. Depending on your link quality
+you may wish to enable more or less by specifying the number.</P>
+
+<P>The other 2 options are dealt with more fully in the security section.</P>
+
+<P>Secondly, it is used to store the login scripts for users and nodes. Currently
+this can only be done by the sysop but it is envisaged that eventually users will
+be able to set their own. An example is included in the distibution but here is
+a further example.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+#
+# G0FYD
+#
+blank +
+sh/wwv 3
+blank +
+sh/dx
+blank +
+t g0jhc You abt?
+blank +
</PRE>
</CODE></BLOCKQUOTE>
-<P>
-<P>There is a lot more on filtering in the next section.
-<P>
+</P>
+<P>The lines in between commands can simply insert a blank line or a character
+such as a + sign to make the output easier to read. Simply create this script
+with your favourite editor and save it with the callsign of the user as the
+filename. Filenames should always be in lower case.</P>
+
+<P>Commands can be inserted in the same way for nodes. A node may wish a series
+of commands to be issued on login, such as a merge command for example.</P>
+
+<P>Thirdly, there are 2 default scripts for users and nodes who do not have a
+specifically defined script. These are <EM>user_default</EM> and
+<EM>node_default</EM></P>
+
<HR>
<A HREF="adminmanual-5.html">Next</A>
<A HREF="adminmanual-3.html">Previous</A>
projects / spider.git / blobdiff