[Dxspider-support] RBN

[Dirk Koopman]

Please upgrade to the latest version in git. If you are not running a 
version derived from the git repository then please carry out the 
actions under the heading "Git" on this page: 
http://www.dxcluster.org/download/

Just to to repeat myself, but in other words  (I do that), do a 'git 
pull' before you start. The instructions are located in the file 
/spider/UPGRADE.mojo.

For those wandering whether to "jump", the instructions are attached.

Dirk G1TLH

On 15/06/18 22:15, Ron Gibson via Dxspider-support wrote:
> Hi Dirk,
> Can we have a reminder as to how to switch to the mojo branch?
> Ron
> VE3CGR
>
> On 6/12/2018 6:31 PM, djk via Dxspider-support wrote:
>>
>> The program rbn.pl is just a simple test program that does some 
>> deduping and a certain amount of checking. There room for 
>> improvement, most of which could be made easier by incorporating it 
>> into the main DXSpider code. Work which I have started doing but, 
>> owing to personal circumstances, has had to take a back seat until 
>> (probably) beginning of July. I have started to put some stubs in 
>> already, but there are a number of issues that I would like to get 
>> some guidance on - here are my current views :
>>
>>   * RBN spots should always be local - meaning that they are not
>>     distributed on the cluster - this implies that each node (that
>>     wants to handle them) will need to make a connection to the RBN.
>>     Note: any spots ending in -# will be dropped by existing DXSpider
>>     nodes so, in fact, it would require a network wide upgrade to
>>     distribute them anyway.
>>   * When the node has established a connection to the RBN, users
>>     should have actively opt in and have a set of RBN specific filter
>>     rules separate from the spot rules.
>>   * Having access to all this realtime signal strength info should
>>     allow some enhanced propagation prediction. Is anyone interested
>>     in this sort of thing and, if so (given that the prediction is
>>     regarded as good) how is to be used by (or communicated to) users?
>>   * Some time ago one of my sysops wrote a program to provide himself
>>     with SMS notifications of spots or conditions that he was
>>     interested in using the filtered output from a connection to a
>>     node. Given that there other means, these days, of informing
>>     users on mobile phones that might be cheaper - should be looking
>>     this? Twitter, Signal or some other mechanism?
>>   * The mojo branch can be considered mature, if not "finished". Any
>>     new features will appear on this branch which will appear,
>>     somewhen, as DXSpider version 2.
>>
>> Discuss.
>>
>> Open to any reasonable suggestions.
>>
>> Dirk G1TLH
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20180616/fbec8146/attachment.html>
-------------- next part --------------
There are the notes for upgrading to the mojo branch.

There is NO POINT in doing this at the moment unless you are running a node with many (>50)
users. It is the future, but at the moment I am testing larger and larger installations to
check that it a) still works as people imagine it should and b) it provides the improvement
in scaling that I am anticipating. There are no significant new features - yet. 

The BIG TICKET ITEM in this branch is that (potentially) "long lived" commands such as sh/dx
and commands that poll external internet resources now don't halt the flow of data through
the node. I am also using a modern, event driven, web socket "manager" called Mojolicious
which is considerably more efficient than what went before (but is not necessary for small
nodes). There are some 200-400 user nodes out there that will definitely see the difference
in terms of both CPU usage and general responsiveness. Using Mojolicious also brings the
tantalising possibility of grafting on a web frontend, as it where, to the "side" of a
DXSpider node. But serious work on this won't start until we have a stable base to work
on. Apart from anything else there will, almost certainly, need to be some internal data
structure reorganisation before a decent web frontend could be constructed.

Upgrading is not for the faint of heart. There is no installation script (but there
will be) so, for the time being, you need to do some manual editing. Also, while there is
a backward path, it will involve moving various files from their new home (/spider/local_data),
back to where they came from (/spider/data).

Prerequisites:

	A supply of good, strong tea - preferably in pint mugs. A tin hat, stout boots, a
	rucksack with survival rations and a decent miners' lamp might also prove comforting. I
	enclose this link: http://www.noswearing.com/dictionary in case you run out of swear words.

	An installed and known working git based installation. Mojo is not supported under CVS or
	installation from a tarball. 

	perl 5.10.1, preferably 5.14.1 or greater. This basically means running ubuntu 12.04 or
	later (or one of the other linux distros of similar age or later). The install instructions are
	for debian based systems. IT WILL NOT WORK WITHOUT A "MODERN" PERL. Yes, you can use
	bleadperl if you know how to use it and can get it to run the node under it as a daemon
	without resorting the handy URL supplied above. Personally, I wouldn't bother. It's
	easier and quicker just to upgrade your linux distro. Apart from anything else things like ssh
	ntpd are broken on ALL older systems and will allow the ungodly in more easily than something
	modern.

Install cpamminus:

	sudo apt-get install cpanminus
or
	sudo apt-get install curl
	curl -L https://cpanmin.us | perl - --sudo App::cpanminus

You will need the following CPAN packages:

	sudo cpanm EV Mojolicious Mojo::IOLoop::ForkCall JSON JSON::XS
	# just in case it's missing
	sudo apt-get install top

Login as the sysop user.

Edit your /spider/local/DXVars.pm so that the bottom of the file is changed from something like:

---- old ----

	 # the port number of the cluster (just leave this, unless it REALLY matters to you)
	 $clusterport = 27754;

	 # your favorite way to say 'Yes'
	 $yes = 'Yes';

	 # your favorite way to say 'No'
	 $no = 'No';

	 # the interval between unsolicited prompts if not traffic
	 $user_interval = 11*60;

	 # data files live in 
	 $data = "$root/data";

	 # system files live in
	 $system = "$root/sys";

	 # command files live in
	 $cmd = "$root/cmd";

	 # local command files live in (and overide $cmd)
	 $localcmd = "$root/local_cmd";

	 # where the user data lives
	 $userfn = "$data/users";

	 # the "message of the day" file
	 $motd = "$data/motd";

	 # are we debugging ?
	 @debug = qw(chan state msg cron );

---- to this: ----

	 # the port number of the cluster (just leave this, unless it REALLY matters to you)
	 $clusterport = 27754;

	 # your favorite way to say 'Yes'
	 $yes = 'Yes';

	 # your favorite way to say 'No'
	 $no = 'No';

	 # this is where the paths used to be which you have just removed
	 
	 # are we debugging ?
	 @debug = qw(chan state msg cron );

---- new  ------

There may be other stuff after this in DXVars.pm, that doesn't matter. The point is to remove
all the path definitions in DXVars.pm. If this isn't clear to you then it would be better if
you asked on dxspider-support for help before attempting to go any further.

One of the things that will happen is that several files currently in /spider/data will be
placed in /spider/local_data. These include the user, qsl and usdb data files, the band and
prefix files, and various "bad" data files. I.e. everything that is modified from the base
git distribution. 

Now run the console program or telnet localhost and login as the sysop user.

	export_users
	bye

as the sysop user:

   sudo service dxspider stop

having stopped the node:

   mkdir /spider/local_data
   git reset --hard
   git pull
   git checkout --track -b mojo origin/mojo

if you have not already done this:

   sudo ln -s /spider/perl/console.pl /usr/local/bin/dx
   sudo ln -s /spider/perl/*dbg /usr/local/bin

Now in another window run:

	watchdbg

and finally:

   sudo service dxspider start

You should be aware that this code base is now under active development and, if you do a 'git pull',
what you get may be broken. But, if this does happen, the likelyhood is that I am actively working
on the codebase and any brokenness may be fixed (maybe in minutes) with another 'git pull'.

I try very hard not to leave it in a broken state...

Dirk G1TLH