X-Git-Url: http://dxcluster.net/gitweb/gitweb.cgi?a=blobdiff_plain;f=html%2Fadminmanual-5.html;h=1ad28e222ef3ad07c480609d8eee3ef8d9274120;hb=d2c1a8cb2a31725e3b9084aee3ec43e585e3273f;hp=ce49bfd9ba6285a23114f37461806b6906408e7c;hpb=09f90105aa04bc675d50b42fa59013a8291696b0;p=spider.git diff --git a/html/adminmanual-5.html b/html/adminmanual-5.html index ce49bfd9..1ad28e22 100644 --- a/html/adminmanual-5.html +++ b/html/adminmanual-5.html @@ -2,134 +2,140 @@ - The DXSpider Installation and Administration Manual : Hop control + The DXSpider Administration Manual v1.48: Databases + Next Previous Contents
-

5. Hop control

+

5. Databases

-

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). +

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.

-

5.1 Basic hop control +

5.1 Creating databases

-

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 ... +

Creating a database could not be more simple. All the commands are +sent from the cluster prompt as the sysop user. +

To create a database you use the command dbcreate. It can +be used in 3 different ways like so ..

-# 
-# 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>
+
+
+

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. +

+

+
+dbcreate <name> chain <name> [<name>...]
 
+

This creates a chained database entry. The first database will be +scanned, then the second, the third etc...

-

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. +

+
+dbcreate <name> remote <name>
+
+
+

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...

-

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. +

+
+dbcreate buckmaster remote gb7dxc
+
+
+

Remote databases cannot be chained, however, the last database in a +chain can be a remote database.

-

5.2 Isolating networks +

5.2 Importing databases

-

It is possible to isolate networks from each other on a "gateway" node using the -set/isolate <node_call> command. +

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. +

To import such a database, first put the file somewhere useful like /tmp +and then issue the following 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. +

+
+dbimport oblast /tmp/OBLAST.FUL
+
+
+

This will update the existing local oblast database or create it if +it does not exist. +

+

5.3 Checking available databases +

+ +

Once a database is created, you will want to check that it has been +added. To do this use the dbavail command. This will +output the available databases. For example ...

-

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. +

+
+dbavail
+DB Name          Location   Chain
+qsl              Local
+buck             GB7ADX
+hftest           GB7DXM
+G0VGS de GB7MBC  3-Feb-2001 1925Z >
+
+

-

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 .... +

5.4 Looking up databases +

+ +

To look for information in a defined database, simply use the dbshow +command, for example ...

-$in = [
-        [ 1, 0, 'd', 0, 3]      # The last figure (3) is the hop count
-];
+dbshow buckmaster G0YLM
 
+

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 +show command like this ...

-

There is a lot more on filtering in the next section. +

+
+'^sh\w*/buc', 'dbshow buckmaster', 'dbshow',
+
+
+

Now you can simply use show/buckmaster or an abreviation. +

+

5.5 Removing databases +

+ +

To delete an existing database you use the dbremove command. +For example ... +

+

+
+dbremove oblast
+
+
+

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.


Next