[Dxspider-support] Updating from DXVars, and several other queries

Wed Sep 2 15:04:29 BST 2015

On 02/09/15 13:02, Martin Davies G0HDB wrote:
> Hello again all, I hope the group can help me with some more queries that have arisen as I've
> continued to tinker with my recently-built GB7DXC-5 node on a Raspberry Pi.....
>
> 1.  A couple of days ago I decided I wanted to make some changes to DXVars.pm but
>      the only way I could find to run 'update_sysop.pl' to bring the changes into effect was
>      firstly by editing /etc/inittab to prevent the cluster running at start-up and then
>      rebooting the system, followed by doing 'update_sysop.pl' to bring the amended
>      DXVars.pm into effect, and finally changing /etc/inittab back again followed by a
>      further reboot to restart the cluster.  Is there a simpler and less disruptive way of
>      updating the system to execute an amended DXVars.pm?

Generally the way to do it via /etc/inittab is to '#' out the line 
starting the node and then to run 'telinit q' as root. This should stop 
the node and allow you to run update_sysop.pl.

When that is done, then un'#' the line in /etc/inittab, run 'telinit q' 
again and it should spring into life.

Perhaps what I should do is create a file for /etc/init.d that uses 
'daemon' to do the respawning and which allows one to do things 
'invoke-rc.d dxspider stop' or 'service dxspider stop' etc. The problem 
with this is that the latest version of debian (which I imagine RPi will 
be using using soon as default) has changed to systemd - which has yet 
another startup system.

There are actually four different systems:

1. /etc/inittab (the original unix way)
2. /etc/init.d (the System V unix way, which has been standard for 
several decades, but doesn't have inherent respawning).
3. upstart  (the system introduced by Ubuntu that replaces both 1 & 2)
4. systemd  (which, for this purpose, is very similar to upstart. It 
does a load of other things as well but isn't relevant to this discussion).

I wish they wouldn't keep changing things. It's very annoying.

> 2.  In connection with the above, is there any way of introducing a delay of say a few
>      mins into the respawning of the cluster after it has been shut down using the
>      'shutdown' command?  When I was trying to run 'update_sysop.pl' after I'd issued a
>      'shutdown' command I found that the cluster was still running and the list of
>      processes seemed to indicate that the cluster had respawned itself immediately after
>      being shut down.  Delaying the respawn for a short time would give a time window in
>      which 'update_sysop.pl' could be run before the cluster restarted.  Is there any way of
>      delaying the respawn?
>

No. (That is a white lie) because there are "correct" ways of stopping & 
starting daemon processes. The respawning happens because, generally, 
that is the correct thing if the node stops by itself.

> 3.  What's the recommended/preferred/definitive procedure for updating the cty.dat file
>      and other related files, and also the cluster s/ware itself?  I've seen various suggested
>      sets of 'git' and CVS commands but my unfamiliarity with Linux means that I'm still
>      not at all sure how to update the system.  A set of step-by-step instructions for
>      updating the various ancillary files and also DXSpider itself will be much appreciated!

This depends on whether you are prepared to rely on my (not always 
timely) updating of cty.dat or not. I believe there are some words about 
this in the admin manual.

In all cases, however the file updating is done (either via a 'git pull' 
or doing it yourself by downloading the file(s) [wpxloc.raw may also 
have been changed], overwriting the one(s) in /spider/data, running 
create_prefix.pl) - you have to do a 'load/prefix' in the sysop command 
window to make them active.

Obviously just doing a 'cd /spider; git reset --hard; git pull' is 
easiest, but may not be as absolutely as up to date as doing it yourself.

>
> 4.  Also related to updating, is there a preferred means of and procedure for updating the
>      Raspbian O/S on the Raspberry Pi?  I've done 'sudo apt-get update' several times to
>      get the latest versions of the packages but have so far refrained from doing 'sudo
>      apt-get upgrade' to install the latest packages in case something gets screwed up.
>      How do other sysops who are running DXSpider on a Pi go about keeping the O/S up
>      to date?

I would personally recommend doing 'apt-get dist-upgrade' rather than 
'apt-get upgrade' as it will also install kernel updates, as well as 
other running "vital" system software.

An other alternative is to install the 'unattended-upgrades' package and 
alter '/etc/apt/apt.conf.d/50unattended-upgrades' to taste. As a minimum 
I would uncomment the line ending in 'updates' in that file:

Unattended-Upgrade::Allowed-Origins {
     "${distro_id}:${distro_codename}-security";
//    "${distro_id}:${distro_codename}-updates";
//    "${distro_id}:${distro_codename}-proposed";
//    "${distro_id}:${distro_codename}-backports";
};

to

Unattended-Upgrade::Allowed-Origins {
     "${distro_id}:${distro_codename}-security";
     "${distro_id}:${distro_codename}-updates";
//    "${distro_id}:${distro_codename}-proposed";
//    "${distro_id}:${distro_codename}-backports";
};

> 5.  Rather than leaving the entire DXSpider system running from the Raspberry Pi's 8GB
>      SD card, thereby hastening the eventual demise of the card because of all the writes
>      to it, I've transferred the entire root filesystem onto a self-powered USB-connected
>      hard disk drive.  This configuration seems to run very well and will hopefully be
>      long-lasting but I'm now beginning to wonder how to take a backup or image of
>      everything that's on the the USB HDD so that I could quickly restore the system in the
>      event of a hard disk failure.  Although I've seen various references to using rsync, dd
>      and dump for making backups - I used rsync as part of the process for transferring
>      the root filesystem from the SD card onto the USB HDD - my unfamiliarity with Linux
>      again means that I'm unsure about the best approach to use.  How do other sysops
>      back-up or image their DXSpider systems, especially while the cluster is running?

I would tend to favour using 'rsync -avz' myself. I would include /etc 
/var as well as /spider in the backup.

> 6.  Is there a command that shows the most recent logins and disconnects of both users
>      and other nodes to and from the node?  I've tried 'sh/log connect' but that seems to
>      take an age to respond, presumably because it has to trawl through all the monthly
>      .dat files.  It would be useful if there was a command that behaved the same way as
>      the AK1A 'sh/log' command but if there is such a command I haven't found it.

You can use sh/log to search for anything. So if you want to see when 
(for instance) g4ezt logged in/out do: 'sh/log g4ezt'. To reduce the 
time taken you can limit it thusly: 'sh/log 4 g4ezt'. What 'sh/log 
connect' does is look for the string 'connect' in the logs. This is 
probably not what the AK1A command does.