<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-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. 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="ss4.1">4.1 Basic hop control</A>
+<H2><A NAME="ss4.1">4.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>
+<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>
+<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>
-<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.
+<H2><A NAME="ss4.2">4.2 Importing databases</A>
+</H2>
+
+<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>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>
+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="ss4.2">4.2 Isolating networks</A>
+<H2><A NAME="ss4.3">4.3 Checking available 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>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 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>
+dbavail
+DB Name Location Chain
+qsl Local
+buck GB7ADX
+hftest GB7DXM
+G0VGS de GB7MBC 3-Feb-2001 1925Z >
+</PRE>
+</CODE></BLOCKQUOTE>
<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.
+<H2><A NAME="ss4.4">4.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>
-<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 ....
+<BLOCKQUOTE><CODE>
+<PRE>
+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>
<BLOCKQUOTE><CODE>
<PRE>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+'^sh\w*/buc', 'dbshow buckmaster', 'dbshow',
</PRE>
</CODE></BLOCKQUOTE>
+<P>Now you can simply use show/buckmaster or an abreviation.
+<P>
+<H2><A NAME="ss4.5">4.5 Removing databases</A>
+</H2>
+
+<P>To delete an existing database you use the <EM>dbremove</EM> command.
+For example ...
<P>
-<P>There is a lot more on filtering in the next section.
+<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-5.html">Next</A>
projects / spider.git / blobdiff