X-Git-Url: http://dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=html%2Fadminmanual-7.html;h=b5a65d3eacc3676b7e8ec8ba611ca0611437c6d4;hb=0c1c82537e95268c2ef2b23b4e9ef317a0119b2d;hp=760c8d926793722daa9b5bb5100ae2520e0a9a7f;hpb=e1f91307fae936112a25ed7ce08f47214ecec766;p=spider.git diff --git a/html/adminmanual-7.html b/html/adminmanual-7.html index 760c8d92..b5a65d3e 100644 --- a/html/adminmanual-7.html +++ b/html/adminmanual-7.html @@ -2,123 +2,93 @@ - The DXSpider Installation and Administration Manual : Other filters + The DXSpider Administration Manual v1.48: Security + Next Previous Contents
-

7. Other filters

+

7. Security

-

7.1 Filtering Mail +

From version 1.49 DXSpider has some additional security features. These +are not by any means meant to be exhaustive, however they do afford some +security against piracy. These two new features can be used independently +of each other or in concert to tighten the security. +

+

7.1 Registration

-

In the /spider/msg directory you will find a file called badmsg.pl.issue. Rename this to badmsg.pl and edit the file. -The original looks something like this .... +

The basic principle of registration is simple. If a user is not registered +by the sysop, then they have read-only access to the cluster. The only +thing they can actually send is a talk or a message to the sysop. In +order for them to be able to spot, send announces or talks etc the sysop +must register them with the set/register command, like this ...

-
-# the list of regexes for messages that we won't store having
-# received them (bear in mind that we must receive them fully before
-# we can bin them)
-
-
-# The format of each line is as follows
-
-#     type      source             pattern 
-#     P/B/F     T/F/O/S            regex  
-
-# type: P - private, B - bulletin (msg), F - file (ak1a bull)
-# source: T - to field, F - from field,  O - origin, S - subject 
-# pattern: a perl regex on the field requested
-
-# Currently only type B and P msgs are affected by this code.
-# 
-# The list is read from the top down, the first pattern that matches
-# causes the action to be taken.
-
-# The pattern can be undef or 0 in which case it will always be selected
-# for the action specified
-
-
-
-package DXMsg;
-
-@badmsg = (
-'B',    'T',    'SALE', 
-'B',    'T',    'WANTED',
-'B',    'S',    'WANTED',
-'B',    'S',    'SALE', 
-'B',    'S',    'WTB',
-'B',    'S',    'WTS',
-'B',    'T',    'FS',
-);
+set/register g0vgs
 
-

-

I think this is fairly self explanatory. It is simply a list of subject headers that we do not want to pass on to either -the users of the cluster or the other cluster nodes that we are linked to. This is usually because of rules and regulations -pertaining to items for sale etc in a particular country. -

-

7.2 Filtering DX callouts -

- -

In the same way as mail, there are some types of spot we do not wish to pass on to users or linked cluster nodes. In the -/spider/data directory you will find a file called baddx.pl.issue. Rename this to baddx.pl and edit the file. The original -looks like this .... +

The user g0vgs can now fully use the cluster. In order to enable +registration, you can issue the command ...

-
-# the list of dx spot addresses that we don't store and don't pass on
-
-
-package DXProt;
-
-@baddx = qw 
-
- FROG 
- SALE
- FORSALE
- WANTED
- P1RATE
- PIRATE
- TEST
- DXTEST
- NIL
- NOCALL 
-);
+set/var $main::reqreg = 1
 
+

Any users that are not registered will now see the motd_nor file rather +than the motd file as discussed in the Information, files and useful +programs section.

-

Again, this is simply a list of names we do not want to see in the spotted field of a DX callout. +

Entering this line at the prompt will only last for the time the cluster +is running of course and would not be present on a restart. To make the +change permanent, add the above line to /spider/scripts/startup. To +read more on the startup file, see the section on Information, files +and useful programs.

+

To unregister a user use unset/register and to show the list +of registered users, use the command show/register.

-

7.3 Filtering words from text fields in Announce, Talk and DX spots +

7.2 Passwords

-

Create a file in /spider/data called badwords. The format is quite -simple. Lines beginning with # are ignored so comments can be added. An -example file is below ... +

At the moment, passwords only affect users who login to a DXSpider +cluster node via telnet. If a user requires a password, they can +either set it themselves or have the sysop enter it for them by using +the set/password command. Any users who already have passwords, +such as remote sysops, will be asked for their passwords automatically +by the cluster. Using passwords in this way means that the user has a +choice on whether to have a password or not. To force the use of +passwords at login, issue the command ...

-# Below is a list of words we do not wish to see on the cluster
-grunge grunged grunging
-splodge splodger splodging
-grince
-fluffle
+set/var $main::passwdreq = 1
 
-

Multiple words can be used on the same line as shown. Obviously these -are just examples :-) +

at the cluster prompt. This can also be added to the /spider/scripts/startup +file as above to make the change permanent.

-

You can reload the file from the cluster prompt as sysop with load/badwords. +

Of course, if you do this you will have to assign a password for each of +your users. If you were asking them to register, it is anticipated that +you would ask them to send you a message both to ask to be registered and +to give you the password they wish to use. +

+

Should a user forget their password, it can be reset by the sysop by +first removing the existing password and then setting a new one like so ... +

+

+
+unset/password g0vgs
+set/password g0vgs new_password
+
+


Next