[Dxspider-support] Permissions

[Dirk Koopman]

I have a similar problem with a VM based system with severely out of 
date Ubuntu (16.04) and my solution was different (and not about the 
fact that the distro was so old it wouldn't upgrade, oh no, not at all, 
never).

I created a new VM, did the few changes that VMs always need 
(users/passwords etc), installed the perl packages and then simply 
rsynced the whole of spider tree across. I then (temporarily) changed 
the node callsign, ran update_sysop.pl and started it up. And it just 
worked. When I'm happy I shall change the node callsign, update the dns, 
stop the old node, rsync the few changes (spots,  logs etc) across, 
start the new node and the dump the old VM.

People forget that it's pure perl and can run on anything (including 
bsd,  Window 95 (please don't), 7 (ditto), 10 or 11 given a decent 
version of perl). The only problem is the (as far as I am concerned) 
obsolescent C client (for ax25 and other non-IP based connections) - and 
that can be solved with a decent C compiler which can be obtained for 
free anyway. 99.5% of sysops will never need to use it. A good 75% of 
the few people that still do, don't need to. But I cannot (and won't) 
diss them because they are mostly long time users that started when we 
were all still using ax25. If it works (and AFAIK it still does) don't 
"fix" it.

73 de Dirk G1TLH

On 06/02/2023 17:28, Kelly Leavit
> My installation was an ongoing update from many years ago. I was 
> alerted by a fellow sysop that I was seriously out of date.
>
> I tried to run the backup/update script 
> (*https://github.com/glaukos78/dxspider_installation_v2/tree/devel 
> <https://github.com/glaukos78/dxspider_installation_v2/tree/devel>*) 
> and found out even my OS was really out of date.
> Updated OS (that alone took two iterations). My site lives on a 
> headless VM server so upgrading the OS was a bit of a challenge but I 
> was able to do it.
>
> I was then able to run the upgrade script as root, but I still got 
> some weird notices about permissions when run.
>
> After a couple of back and forth emails I decided to shut down the 
> site and change ownership of everything in the spider directory to sysop.
>
> I changed into the install directory and did
> sudo find . -exec chown sysop {} \;
>
> The I restarted the service. Everything seems to be much more stable now.
>
> I think I'm going to do a clean install on a new instance to verify 
> what the permissions on everything should be and clean up the mess I have.
>
> 73 de Kelly, KE2L
>
> ------------------------------------------------------------------------
> *From:* Dxspider-support <dxspider-support-bounces at tobit.co.uk> on 
> behalf of Dirk Koopman via Dxspider-support <dxspider-support at tobit.co.uk>
> *Sent:* Monday, February 6, 2023 10:11 AM
> *To:* Dxspider-Support <dxspider-support at dxcluster.org>
> *Cc:* Dirk Koopman <djk at tobit.co.uk>
> *Subject:* [Dxspider-support] Permissions
> There are some recent reports about permissions being changed after 
> updates.
>
> I should like to see some concrete evidence of the sort of these 
> permission changes, in order to determine where the problem is. But I 
> will make one observation: users *_must_* be the sysop user when doing 
> an update. Doing an update _as root_ may (or more likely) _not_ give 
> you the (velvety) smooth experience that (I'm sure [honest :-]) that 
> you are used to.
>
> If you do experience "permission problems" please send me examples + 
> how you went about doing the failing update.
>
> 73 Dirk G1TLH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20230207/c930a2be/attachment.htm>