Databases and Node configuration for user access: Difference between pages

From The DXSpider Documentation Wiki
(Difference between pages)
Jump to navigation Jump to search
(Created page with "==Databases== 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. ===Creating databases=== Creating a database could not be more simple. All the commands are sent from the cluster prompt as the sysop user. To c...")
 
 
Line 1: Line 1:
==Databases==


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.


===Creating databases===
==='''User Registration'''===
----
There are two types of user in a DXSpider node, a registered user and an unregistered user.
By default, all users belong to the unregistered category.


Creating a database could not be more simple.  All the commands are sent from the cluster prompt as the sysop user.
==='''Node in UNREGISTERED Mode'''===
----
This is the default way of working, but not necessarily the best.


To create a database you use the command dbcreate.  It can be used in 3 different ways like so ..
The global variable that sets the node type is '''$main::reqreg'''
and its default value is '''0'''.
<pre>
  set/var $main::reqreg = 0
</pre>


dbcreate <name>
In this mode the sysop doesn't have to to register users, but if they are registered, then it will simply be a database entry.
Both types of user will have the same capabilities to send and receive SPOTS, ANN, etc


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.
==='''Node in REGISTRATION Mode'''===
----
To activate registration, the global variable '''$main::reqreg''' must be set to '''1'''.
The way to change it is


dbcreate <name> chain <name> [<name>...]
<pre>
  set/var $main::reqreg = 1
</pre>


This creates a chained database entry.  The first database will be scanned, then the second, the third etc...
When this mode is activated, only users that the sysop has registered will be able to send and receive SPOTS, ANN, etc. Unregistered users will only be able to receive information.


dbcreate <name> remote <name>
The way to register/unregister a user is as follows:
<pre>
  set/register <call>
  unset/register <call>
</pre>


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 check which users we have registered using


dbcreate buckmaster remote gb7dxc
<pre>
  sh/register <call>
</pre>


Remote databases cannot be chained, however, the last database in a chain can be a remote database.
A specific login banner for registered users can be shown. The file containing it is the following


===Importing databases===
<pre>
  /spider/_local_data/motd
</pre>


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.
When an unregistered user starts the login process, they can be sent a different file that can be configured to say that they are not registered and how to register should they wish to do so. This file is ...


To import such a database, first put the file somewhere useful like /tmp and then issue the following command ...
<pre>
  /spider/local_data/motd_nor
</pre>


  dbimport oblast /tmp/OBLAST.FUL
==='''Password Usage'''===
----
By default, a user does not get prompted for a password at login. For additional security, a user can request a password be set for them. They simply need to request a password that they provide to the sysop.


This will update the existing local oblast database or create it if it does not exist.
It should be noted that this only works on the node they regularly use.  Their password is not propagated across the network for security reasons.


===Checking available databases===
For a user to be assigned a password, the sysop needs to use the command ...


Once a database is created, you will want to check that it has been added.  To do this use the �[4mdbavail�[24m command.  This will output the available databases.  For example ...
<pre>
  set/password <call> <string>
</pre>


dbavail
and the user can change his password with the command
DB Name          Location  Chain
qsl              Local
buck            GB7ADX
hftest          GB7DXM
G0VGS de GB7MBC  3-Feb-2001 1925Z >


===Looking up databases===
<pre>
  set/password ****(I am not sure this is true?)
****</pre>


To look for information in a defined database, simply use the dbshow command, for example ...
==='''Node in NO PASSWORD Mode'''===
----
The global variable '''$main::passwdreq''' is set to '''0''' by default.
As mentioned above, users logging into a node so configured will only be prompted for their callsign.


dbshow buckmaster G0YLM
To see the value of the variable we will use
<pre>
  sh/var $main::passwdreq
</pre>


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


Now you can simply use show/buckmaster or an abreviation.
==='''Node in PASSWORD Mode'''===
----
If we set the '''$main::passwdreq''' variable to '''1''', we will force any user logging in to the node to enter their callsign and password, otherwise they will not be able to access the node.
The node will not establish the session if there is no positive authentication.


===Removing databases===
To set this mode of operation:
<pre>
  set/var $main::passwdreq = 1
</pre>


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


dbremove oblast
==='''How To Protect Node (Recommended configuration)'''===
----
One way to control the correct use of our node, is to use the combination of registration and password as follows.


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.
We enable the registration for all the users
<pre>
  set/var $main::reqreg = 1
</pre>
and we disable the global use of passwords
<pre>
  set/var $main::passwdreq = 0
</pre>
This allows anyone to access the node in READ mode, but only those who have authenticated with username and password will have full user access.
 
This implies that the sysop must register and assign a password to the trusted user.
<pre>
  set/register <call>
  set/password <call> <string>
</pre>
This way we have control and limit the misuse of our node.
 
 
==='''Make Changes Permanent'''===
----
Although we can enable or disable these variables at any time, if we want to keep them during the startup of the node, we must edit the file
<pre>
  /spider/scripts/startup
</pre>
and include the following lines
<pre>
  set/var $main::reqreg = 1
  set/var $main::passwdreq = 0
</pre>
The changes to this file will not take effect until there is a reboot, so we can activate it manually the first time from the console by typing
<pre>
  set/var $main::reqreg = 1
  set/var $main::passwdreq = 0
</pre>

Revision as of 14:09, 10 February 2023


User Registration

There are two types of user in a DXSpider node, a registered user and an unregistered user. By default, all users belong to the unregistered category.

Node in UNREGISTERED Mode

This is the default way of working, but not necessarily the best.

The global variable that sets the node type is $main::reqreg and its default value is 0. 

  set/var $main::reqreg = 0

In this mode the sysop doesn't have to to register users, but if they are registered, then it will simply be a database entry. Both types of user will have the same capabilities to send and receive SPOTS, ANN, etc

Node in REGISTRATION Mode

To activate registration, the global variable $main::reqreg must be set to 1. The way to change it is 

  set/var $main::reqreg = 1

When this mode is activated, only users that the sysop has registered will be able to send and receive SPOTS, ANN, etc. Unregistered users will only be able to receive information.

The way to register/unregister a user is as follows: 

  set/register <call>
  unset/register <call>

You can check which users we have registered using 

  sh/register <call>

A specific login banner for registered users can be shown. The file containing it is the following 

  /spider/_local_data/motd

When an unregistered user starts the login process, they can be sent a different file that can be configured to say that they are not registered and how to register should they wish to do so. This file is ... 

  /spider/local_data/motd_nor

Password Usage

By default, a user does not get prompted for a password at login. For additional security, a user can request a password be set for them. They simply need to request a password that they provide to the sysop.

It should be noted that this only works on the node they regularly use. Their password is not propagated across the network for security reasons.

For a user to be assigned a password, the sysop needs to use the command ... 

  set/password <call> <string>

and the user can change his password with the command 

  set/password ****(I am not sure this is true?)
****

Node in NO PASSWORD Mode

The global variable $main::passwdreq is set to 0 by default. As mentioned above, users logging into a node so configured will only be prompted for their callsign.

To see the value of the variable we will use 

  sh/var $main::passwdreq


Node in PASSWORD Mode

If we set the $main::passwdreq variable to 1, we will force any user logging in to the node to enter their callsign and password, otherwise they will not be able to access the node. The node will not establish the session if there is no positive authentication.

To set this mode of operation: 

  set/var $main::passwdreq = 1


How To Protect Node (Recommended configuration)

One way to control the correct use of our node, is to use the combination of registration and password as follows.

We enable the registration for all the users 

  set/var $main::reqreg = 1

and we disable the global use of passwords 

  set/var $main::passwdreq = 0

This allows anyone to access the node in READ mode, but only those who have authenticated with username and password will have full user access.

This implies that the sysop must register and assign a password to the trusted user. 

  set/register <call>
  set/password <call> <string>

This way we have control and limit the misuse of our node.


Make Changes Permanent

Although we can enable or disable these variables at any time, if we want to keep them during the startup of the node, we must edit the file 

  /spider/scripts/startup

and include the following lines 

  set/var $main::reqreg = 1
  set/var $main::passwdreq = 0

The changes to this file will not take effect until there is a reboot, so we can activate it manually the first time from the console by typing 

  set/var $main::reqreg = 1
  set/var $main::passwdreq = 0
Retrieved from ‘https://wiki.dxcluster.org/index.php?title=Databases&oldid=83’