Allows running under another user and non-raspberrypi hardware

[rhaamo]

I wanted to install this on a server I already had and not a dedicated pi so I tried to make the whole install part and run more user/hw/sw agnostic.

TLDR: made able to run on another user than pi and hardware than a pi.

My changes are:

• enabled facts gathering (I used some)
• added own build of medet for amd64 (you can replace it if you want)
• added deb for wxtoimg for amd64 (same)
• install of the last two depending on if the CPU arch from the facts is armv7l or not (I only have one pi arch to test the value content)
• added a few config/ansible variables:
  • running_under_user, default pi, the user the app will run under
  • running_under_group, same but for the group
  • use_ntpd: default true, will include or not ntp.yml
  • use_ramfs: default true, will include or not ramfs.yml
  • setup_webserver: default true, include nginx/php install and setup
• nginx & php install/setup has been split from the app config
• replacement of /home/pi in two files by ansible using the running_under_user var
• used running_under_user instead of hardcoded pi in various ansible templates
• added a check for another path for rtl_sdr (was on /usr/bin instead of /usr/local/bin here)
• replaced raspbian_version by fact ansible_distribution_release
• predict is installed from repos when stretch, and from stretch deb file if != stretch (not packaged anymore after stretch)
• added the user and group running under in noaa-v2.conf to be used for install script and anything else that could use it
• added the user in Config/Config.php and used it in AdminController.php for sudo command

NOTES:

• One of the issues I see would be with the subst in two files (see common/tasks/user.yml) that will break git pull but I don't see how to properly handle that, except by excluding the scripts from git (the scripts/xxxx.ext), making them templates (scripts/xxxx.ext.j2), and having ansible generating the 'final' ones.

• Also in scripts/common.sh, rtl_fm isn't always in /usr/local/bin (like rtl_sdr) but might be in /usr/bin, maybe we can add detection in ansible and fill noaa-v2.conf with it.

• Documentation has not been updated so depending on the config used (setup_webserver etc.) the install will not be 100% operational.

• This PR should also fixes #108

• I don't have an available raspberrypi to test it, it only has been tested on my server (running Ubuntu 20.04.3 LTS)

• Gnuradio scripts are for python2 BUT seems easy to use python3, noaa one needs indentation fixed (mix tabs/spaces) + python3 on first line, and only first line for meteor

Here is one okay-ish (the pass seemed to have been shorted because of an overlapping meteor one) pass from my install:

[dom-robinson]

Wow - what an awesome PR to come in out of the blue! Thank you so much!

This is quite an involved development to pick through and test, and we are all working on this in spare time so it may take some time to build the momentum to get this through to live, but strongly encourage it to happen!

@colinluthier @Cadair check this out!

Dom

[Cadair]

:heart: Thank you so much for this, it looks great. I shall try and look over it (and maybe even try and deploy it on my server) this weekend and see how I go.

[Cadair]

Gnuradio scripts are for python2 BUT seems easy to use python3, noaa one needs indentation fixed (mix tabs/spaces) + python3 on first line, and only first line for meteor

OH that's why that worked!! Stupid Python 2 still existing.

[rhaamo]

I have fixed ramfs_path missing the {{ }} and used the vars for user and group.

The METEOR stuff uses the ramfs path, so if not choosen to be deployed the user handle it, and if choosen it will have the right user and group instead of fixed pi (somehow missed that)

[dom-robinson]

@Cadair in particular, but checking with @colinluthier too - looks ok to me, but can i get a second vote before i merge?

[colinluthier]

I think this needs to remain a draft till the documentation is caught up. Also, a couple of the issues he notes could be cleaned up first. I don't have time right now but I would like to see if settings.yml is getting checked for the new vars completely.

[rhaamo]

I can take a look at what can be updated in the docs this week. For settings.yml IIRC I already updated the schema with the new keys.

[colinluthier]

I just got a chance to read through it. settings.yml.sample was not changed and needs to be updated, unless I missed it. Also, the new variables need to be added to raspberry-noaa-v2/config/settings_schema.json. The PR looks great and we really appreciate the help.

[leonardpitzu]

No update on this one? I would like to migrate away from pi and more to docker stuff on an Intel based server. I'll keep the pi only as a remote sdr server connected to the antenna, in my garden, where it's hard for a server to sit.

[MihajloPi]

Implemented amd64 support alongside the native armhf for Raspberry Pi and X96 Android boxes with flashed Raspberry OS.