<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>The DXSpider Installation and Administration Manual : Hop control</TITLE>
+ <TITLE>The DXSpider Administration Manual v1.48: Databases</TITLE>
<LINK HREF="adminmanual-6.html" REL=next>
<LINK HREF="adminmanual-4.html" REL=previous>
<LINK HREF="adminmanual.html#toc5" REL=contents>
+<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
</HEAD>
<BODY>
<A HREF="adminmanual-6.html">Next</A>
<A HREF="adminmanual-4.html">Previous</A>
<A HREF="adminmanual.html#toc5">Contents</A>
<HR>
-<H2><A NAME="s5">5. Hop control</A></H2>
+<H2><A NAME="s5">5. Databases</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>Spider allows the creation of local or remote databases. It supports
+chained databases, allowing several different databases to be scanned
+with one simple command. Importing of databases is limited at present
+to the standard AK1A databases such as OBLAST and the DB0SDX QSL
+database but will expand with time.
<P>
-<H2><A NAME="ss5.1">5.1 Basic hop control</A>
+<H2><A NAME="ss5.1">5.1 Creating databases</A>
</H2>
-<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>Creating a database could not be more simple. All the commands are
+sent from the cluster prompt as the <EM>sysop</EM> user.
+<P>To create a database you use the command <EM>dbcreate</EM>. It can
+be used in 3 different ways like so ..
<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,
- },
-};
+dbcreate <name>
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>To simply create a database locally, you just tell the command the
+name of the database. This does not create the actual database, it
+simply defines it to say that it exists.
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+dbcreate <name> chain <name> [<name>...]
</PRE>
</CODE></BLOCKQUOTE>
+<P>This creates a chained database entry. The first database will be
+scanned, then the second, the third etc...
<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.
+<BLOCKQUOTE><CODE>
+<PRE>
+dbcreate <name> remote <name>
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This creates a remote entry. the first name field is the database
+name at the remote node, then the remote switch, then the actual
+node_call of the remote node, for example...
<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.
+<BLOCKQUOTE><CODE>
+<PRE>
+dbcreate buckmaster remote gb7dxc
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Remote databases cannot be chained, however, the last database in a
+chain can be a remote database.
<P>
-<H2><A NAME="ss5.2">5.2 Isolating networks</A>
+<H2><A NAME="ss5.2">5.2 Importing databases</A>
</H2>
-<P>It is possible to isolate networks from each other on a "gateway" node using the
-<EM>set/isolate <node_call></EM> command.
+<P>The only databases that Spider can currently import are the standard
+AK1A databases such as OBLAST or the DB0SDX qsl and address database.
+This will be added to with time.
+<P>To import such a database, first put the file somewhere useful like /tmp
+and then issue the following 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.
+<BLOCKQUOTE><CODE>
+<PRE>
+dbimport oblast /tmp/OBLAST.FUL
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This will update the existing local oblast database or create it if
+it does not exist.
+<P>
+<H2><A NAME="ss5.3">5.3 Checking available databases</A>
+</H2>
+
+<P>Once a database is created, you will want to check that it has been
+added. To do this use the <EM>dbavail</EM> command. This will
+output the available databases. For example ...
<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.
+<BLOCKQUOTE><CODE>
+<PRE>
+dbavail
+DB Name Location Chain
+qsl Local
+buck GB7ADX
+hftest GB7DXM
+G0VGS de GB7MBC 3-Feb-2001 1925Z >
+</PRE>
+</CODE></BLOCKQUOTE>
<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 ....
+<H2><A NAME="ss5.4">5.4 Looking up databases</A>
+</H2>
+
+<P>To look for information in a defined database, simply use the <EM>dbshow</EM>
+command, for example ...
<P>
<BLOCKQUOTE><CODE>
<PRE>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+dbshow buckmaster G0YLM
</PRE>
</CODE></BLOCKQUOTE>
+<P>will show the information for the callsign G0YLM from the buckmaster
+database if it exists. To make things more standard for the users
+you can add an entry in the Aliases file so that it looks like a standard
+<EM>show</EM> command like this ...
<P>
-<P>There is a lot more on filtering in the next section.
+<BLOCKQUOTE><CODE>
+<PRE>
+'^sh\w*/buc', 'dbshow buckmaster', 'dbshow',
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Now you can simply use show/buckmaster or an abreviation.
+<P>
+<H2><A NAME="ss5.5">5.5 Removing databases</A>
+</H2>
+
+<P>To delete an existing database you use the <EM>dbremove</EM> command.
+For example ...
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+dbremove oblast
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>would remove the oblast database and its associated datafile from the
+system. There are no warnings or recovery possible from this command.
+If you remove a database it ceases to exist and would have to be created
+from scratch if you still required it.
<P>
<HR>
<A HREF="adminmanual-6.html">Next</A>
projects / spider.git / blobdiff