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

[Martin Davies G0HDB]

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?

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?

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!  

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?

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?

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.

7.  Also relating to showing logins to and disconnects from the node, I see that a normal 
    user gets a 'Not allowed' response when trying to do 'sh/log connect'.  What's the 
    rationale behind preventing a user seeing this information, and is there any way of 
    enabling a user to see the login/disconnect log?

8.  Finally, back to spot filtering - when I was playing around with filters a couple of 
    weeks ago I followed some of the guidance and examples given in the filtering 
    manual and tried 'reject/spot on 4m and on 2m and on 70cm' but this didn't seem to 
    give the expected result because I was still receiving spots on some of those bands.  
    It then occurred to me that the filter might only reject spots that appeared on 
    4m_AND_2m_AND_70cms of which there are presumably very few(!), so instead I 
    tried 'reject/spot on 4m or on 2m or on 70cm' and this seems to have achieved the 
    desired result.  Have I missed something, or does the filtering guidance need to be 
    amended slightly to make clear the difference between AND'ing and OR'ing?

Thanks in advance for any and all responses that the above might generate!

--
73, Martin G0HDB


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus