Node configuration for user access: Difference between revisions

From The DXSpider Documentation Wiki
Jump to navigation Jump to search
No edit summary
 
(12 intermediate revisions by 2 users not shown)
Line 3: Line 3:
==='''User Registration'''===
==='''User Registration'''===
----
----
There are two categories of user in a DXSpider node, the registered user and the unregistered user.  
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.
By default, all users belong to the unregistered category.


==='''Node in UNREGISTERED Mode'''===
==='''Node in UNREGISTERED Mode'''===
----
----
This is the most extedited way of working, but not necessarily the best.
This is the default way of working, but not necessarily the best.


The global variable that conditions the node is '''$main::reqreg'''
The global variable that sets the node type is '''$main::reqreg'''
and its default value is '''0'''.
and its default value is '''0'''.
<pre>
<pre>
Line 17: Line 16:
</pre>
</pre>


In this mode the sysop is not obliged to register users, but if it does register them it will simply be a database entry.
In this mode the sysop doesn't have to register users, but if they are registered, then it will simply be a database entry.
Both types of users will have the same capabilities to send and receive SPOTS, ANN, ...
Both types of user will have the same capabilities to send and receive SPOTS, ANN, etc
 
When the user starts the login process, he will be sent (if it exists) the banner contained in the file
<pre>
  /spider/local_data/motd_nor
</pre>
 


==='''Node in REGISTRATION Mode'''===
==='''Node in REGISTRATION Mode'''===
----
----
To use this mode, the global variable '''$main::reqreg''' must be set to '''1'''.
To activate registration, the global variable '''$main::reqreg''' must be set to '''1'''.
The way to change it is
The way to change it is
<pre>
<pre>
   set/var $main::reqreg = 1
   set/var $main::reqreg = 1
</pre>
</pre>


When this mode is activated, only users that the sysop has registered will be able to send and receive SPOTS, ANN, ..., while unregistered users will only be able to receive information.
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:
The way to register/unregister a user is as follows:
Line 41: Line 35:
   unset/register <call>
   unset/register <call>
</pre>
</pre>
At any time we can know which users we have registered using
 
You can check which users we have registered using
 
<pre>
<pre>
   sh/register
   sh/register <call>
</pre>
</pre>
There is the possibility to display a specific banner for registered users. The file containing it is the following
 
A specific login banner for registered users can be shown. The file containing it is the following
 
<pre>
<pre>
   /spider/_local_data/motd
   /spider/_local_data/motd
</pre>
</pre>


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 ...
<pre>
  /spider/local_data/motd_nor
</pre>


==='''Password Usage'''===
==='''Password Usage'''===
----
----
By default, the node has disabled the function of requesting a password when we log in. So there is a risk that another user can use our account.
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 ...


For a user to be assigned a password, the sysop will have to execute at least once
<pre>
<pre>
   set/password <call> <string>
   set/password <call> <string>
</pre>
</pre>
and the user can change his password with the command
and the user can change his password with the command
<pre>
<pre>
   set/password
   set/password
Enter old password:
Enter new password:
Re-enter new password:
  Password changed
</pre>
</pre>


==='''Node in NO PASSWORD Mode'''===
==='''Node in NO PASSWORD Mode'''===
----
----
The global variable '''$main::passwdreq''' is set to '''0''' by default.
The global variable '''$main::passwdreq''' is set to '''0''' by default. This does not mean that they cannot have a password set, only that users are not forced to have a password.
As mentioned above, users logging into a node so configured will only be prompted for their callsign.
 
 
To see the value of the variable use ...


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


==='''Node in PASSWORD Mode'''===
==='''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.
If we set the '''$main::passwdreq''' variable to '''1''', we will force any user logging in to the node to use a password as well as their callsign, otherwise they will not be able to access the node.
 
The node will not establish the session if there is no positive authentication.
The node will not establish the session if there is no positive authentication.


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


==='''How To protect your cluster node (Recommended configuration)'''===


==='''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.
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
We enable the registration for all the users
<pre>
<pre>
   set/var $main::reqreg = 1
   set/var $main::reqreg = 1
</pre>
</pre>
and we disable the global use of passwords
 
The beauty of this is that people who try to login with callsigns like ID1OT or even using random callsigns cannot post spots or announcements from the node.
 
Unless the cluster node is a small club node or similar, it is probably a good idea not to force people to have a password.  It may put some people off and it will be a LOT of work for the sysop.  Most users will be protected by registration
 
<pre>
<pre>
   set/var $main::passwdreq = 0
   set/var $main::passwdreq = 0
</pre>
</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.
Of course, a user may wish to have a password set to increase their security on the node, meaning that unless someone also knows the password, their call cannot be used by someone else unless they know the password.
 
<pre>
<pre>
   set/register <call>
   set/register <call>
   set/password <call> <string>
   set/password <call> <string>
</pre>
</pre>
This way we have control and limit the misuse of our node.


It is <b>strongly</b> suggested that sysops enable registration to try and combat the increasing misuse on the cluster network


==='''Make Changes Permanent'''===
==='''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  
Although sysops can enable or disable these variables at any time from the console, this will only be enabled until the node is restarted. if we want to keep them during the startup of the node, we must edit the file ...
 
<pre>
<pre>
   /spider/scripts/startup
   /spider/scripts/startup
</pre>
</pre>
and include the following lines
and include the following lines
<pre>
<pre>
Line 120: Line 140:
   set/var $main::passwdreq = 0
   set/var $main::passwdreq = 0
</pre>
</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
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>
<pre>

Latest revision as of 17:54, 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 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
	Enter old password:
	Enter new password:
	Re-enter new password:
  Password changed

Node in NO PASSWORD Mode

The global variable $main::passwdreq is set to 0 by default. This does not mean that they cannot have a password set, only that users are not forced to have a password.


To see the value of the variable 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 use a password as well as their callsign, 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 your cluster 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

The beauty of this is that people who try to login with callsigns like ID1OT or even using random callsigns cannot post spots or announcements from the node.

Unless the cluster node is a small club node or similar, it is probably a good idea not to force people to have a password. It may put some people off and it will be a LOT of work for the sysop. Most users will be protected by registration 

  set/var $main::passwdreq = 0

Of course, a user may wish to have a password set to increase their security on the node, meaning that unless someone also knows the password, their call cannot be used by someone else unless they know the password. 

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

It is strongly suggested that sysops enable registration to try and combat the increasing misuse on the cluster network

Make Changes Permanent

Although sysops can enable or disable these variables at any time from the console, this will only be enabled until the node is restarted. 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=Node_configuration_for_user_access&oldid=90’