[Dxspider-support] Discussion set/register set/password

[Anthony(N2KI)]

What kind of improper use are you seeing?  

 

 

Anthony - N2KI

30MDG - 1187

 www.n2ki.com

 

 

-----Original Message-----
From: dxspider-support-bounces at dxcluster.org [mailto:dxspider-support-bounces at dxcluster.org] On Behalf Of Ian Maude
Sent: Sunday, October 25, 2009 1:35 PM
To: The DXSpider Support list
Subject: Re: [Dxspider-support] Discussion set/register set/password

 

Well I can certainly give you my opinion :)

I run registration on both the clusters I admin.  I do not have a mandatory password policy as it only counts for the one
cluster anyway.  It is also a LOT of work for the sysop.  Please do consider registration though as it really does help the
network.  I feel this will become more and more important in the years to come and we need to get ahead of it now!

 

Dirk, could you make it possible to export a list of registered users please in case of crash etc?  It would be a really
useful addition.

 

73 Ian

 

-- 
Ian J Maude, G0VGS
SysOp GB7MBC & HB9DRV-9 DX Clusters
Member RSGB, GQRP 9838, FISTS 14077 | K3 #455
http://www.amateurradiotraining.org 

 

2009/10/25 Luigi Carlotto, IK5ZUK <ik5zuk at tiscali.it>

Hi Wolfram, hi all.
I'm totally agree with you, Wolfram.

In order to discourage any improper use, at my cluster I've enabled the registration (set/var $main::regreq = 1) and for any
registered call I've set (manually) a password. This is the better way, IMHO, because my node is open for everybody via
internet in "passive" mode, and to become active is needed the registration by the sysop and a password.

It should be nice to share the password database using a new PC protocol sting, but this solution hasn't an high level
security.
Another solution may be to have a remote password database, stored in one (two or three for redundancy) server reachable via
internet, so that spider can aks/verify to those servers the password for the user's connection... but in this way if the
servers are not reachable, the cluster network became unopened to any connection.

Another problem to this question, is that today we can see in our network some spider nodes still running a very old
release... and it is very important that all nodes, with no exceptions, runs a new release and with the same policy !

Here in Italy we have a Yahoo! group (http://groups.yahoo.com/group/retedxcitalia) in order to coordinate the  job for all
the italian sysops, but I must admit that we have discussed this problem some times and since today we haven't obtained a
single policy to apply to our cluster nodes, due to diverging opinions... And we are only a little number in comparison to
the total cluster nodes spreaded across the world !

Dirk, please, could you tell us your opinion ?!?

73 de Luigi, ik5zuk

 

Hello

at the last time are more and more "black-user" (improper use) in the
cluster-net with any spam and false spots...
Badspotter, badwords or badnodes are a posssibility. But the calls are
imaginative or they use simple a existing call....

The problem is that the clusternet via internet is open for everybody and
nobody    have control for the calls. I dont want to deny the access for the
user to read the spots - but there has to be a simple control for the spotter.

set/password is no the solution. You get a question for the password and if
you have not set a password you can log in with "ENTER" and have all
functions. If you set a password it is local to this cluster and there are
still about 400 cluster without password for you (better - or worse - for the
blacks..)
(a possibility can be - forwarding for the passwords - the most clusters are
dxspider - is it possible to do it  Dirk?)

With "register on" it is possible to read all clusterinformation. No spots and
no ann are possible to send. Only send a mail to sysop....

I have now set at db0erf-5:

set/var $main::regreq = 1
set/var $main::passwdreq = 1

I think if more (best all) sysop take these regulations we have less trouble....

73 from Erfurt de Wolfram DL3AMi


_______________________________________________
Dxspider-support mailing list
Dxspider-support at dxcluster.org
http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20091025/56cc833d/attachment-0001.htm>