Added information on registration, login scripts and passwords to the
[spider.git] / html / adminmanual-7.html
index 760c8d926793722daa9b5bb5100ae2520e0a9a7f..b5a65d3eacc3676b7e8ec8ba611ca0611437c6d4 100644 (file)
 <HTML>
 <HEAD>
  <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>The DXSpider Installation and Administration Manual : Other filters</TITLE>
+ <TITLE>The DXSpider Administration Manual v1.48: Security</TITLE>
  <LINK HREF="adminmanual-8.html" REL=next>
  <LINK HREF="adminmanual-6.html" REL=previous>
  <LINK HREF="adminmanual.html#toc7" REL=contents>
+<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
 </HEAD>
 <BODY>
 <A HREF="adminmanual-8.html">Next</A>
 <A HREF="adminmanual-6.html">Previous</A>
 <A HREF="adminmanual.html#toc7">Contents</A>
 <HR>
-<H2><A NAME="s7">7. Other filters</A></H2>
+<H2><A NAME="s7">7. Security</A></H2>
 
-<H2><A NAME="ss7.1">7.1 Filtering Mail</A>
+<P>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.
+<P>
+<H2><A NAME="ss7.1">7.1 Registration</A>
 </H2>
 
-<P>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 ....
+<P>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 <EM>set/register</EM> command, like this ...
 <P>
 <BLOCKQUOTE><CODE>
 <PRE>
-
-# 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
 </PRE>
 </CODE></BLOCKQUOTE>
-<P>
-<P>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.
-<P>
-<H2><A NAME="ss7.2">7.2 Filtering DX callouts</A>
-</H2>
-
-<P>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 ....
+<P>The user g0vgs can now fully use the cluster.  In order to enable 
+registration, you can issue the command ...
 <P>
 <BLOCKQUOTE><CODE>
 <PRE>
-
-# 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
 </PRE>
 </CODE></BLOCKQUOTE>
+<P>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.
 <P>
-<P>Again, this is simply a list of names we do not want to see in the spotted field of a DX callout.
+<P>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.
 <P>
+<P>To unregister a user use <EM>unset/register</EM> and to show the list
+of registered users, use the command <EM>show/register</EM>.
 <P>
-<H2><A NAME="ss7.3">7.3 Filtering words from text fields in Announce, Talk and DX spots</A>
+<H2><A NAME="ss7.2">7.2 Passwords</A>
 </H2>
 
-<P>Create a file in /spider/data called <EM>badwords</EM>.  The format is quite
-simple.  Lines beginning with # are ignored so comments can be added.  An
-example file is below ...
+<P>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 <EM>set/password</EM> 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 ...
 <P>
 <BLOCKQUOTE><CODE>
 <PRE>
-# 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
 </PRE>
 </CODE></BLOCKQUOTE>
-<P>Multiple words can be used on the same line as shown.  Obviously these
-are just examples :-)
+<P>at the cluster prompt.  This can also be added to the /spider/scripts/startup
+file as above to make the change permanent.
 <P>
-<P>You can reload the file from the cluster prompt as sysop with load/badwords.
+<P>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.
+<P>
+<P>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 ...
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+unset/password g0vgs
+set/password g0vgs new_password
+</PRE>
+</CODE></BLOCKQUOTE>
 <P>
 <HR>
 <A HREF="adminmanual-8.html">Next</A>