Fully converting installation script to Ansible

[lwilson2048]

Hello,

I have almost completely converted the installation script to Ansible tasks. I believe doing this greatly increases the readability of the installation code. The only parts remaining are the ".chroot" files received from the GitHub hook. This part of the process I have left the same because I do not fully understand its purpose.

Ansible is still evoked in the same way as before. The Ansible playbook can determine which distro and release it is being run on automatically. Setting the remote_user for each remote host can be done in the inventory file as explained here.

I have tested this on Debian Buster and Ubuntu Bionic on X86_64 and Raspbian Lite (which is really Debian Buster) on armv7l (a Raspberry Pi 4b).

I removed lsb-release from the packages list because it is pre-installed on the releases I tested.

If there are any other distros/releases/architectures you'd like supported I can add them fairly easily.

Issues:

• The code manually creates a functionally empty file to "/var/log/cloud/cloudynitzar.log". This is a workaround because Ansible doesn't offer an obvious way to copy a playbook's logs onto the target remote host. The full logs are still available on the local host.
• On Buster test "03_web_interface_login" fails. This failure also occurs for me when using the standard cloudynitzar script.
• Updating the cache fails after adding the Guifi repository key. This failure also occurs for me when using the standard cloudynitzar script. The failures are reported but ignored and do not appear to effect proper function.

[rogerpueyo]

Hi @lwilson2048,

Thanks for opening this PR. That's an amazing contribution! I'll be reviewing in the coming days it, but please let us know when it's ready for merging.

We wonder how did you learn about Cloudy, or what made you work on porting the installation process to Ansible. Feel free to tell us, if you feel like.

Best,

Roger

[lwilson2048]

Hi!

This is embarrassing, but I realized I messed up this pull request. I had assumed that after opening it I could continue making commits to the ansible branch of my fork. I didn't realize it would add each commit to this request. The specific commit I intended this for is b3d1c36a25b1cb35d996488fd2206c0949b217a5. The commits beyond b3d1c36a25b1cb35d996488fd2206c0949b217a5 are all related to building a k3s cluster via Ansible, which I should have done in a separate branch. I apologize for the mistake.

I first came across Cloudy a few months ago while researching things for my project Honeybee. Unfortunately, at the time I didn't look into Cloudy enough to realize that Honeybee was trying to do more or less the same thing. I re-encountered it about a week ago while reading some things from Netcommons. My goal with Honeybee was to create a Wireless mesh network and ISP organized as a user cooperative and then build a cloud environment on top of that. Similar to Cloudy and Guifi but adapted to the legal and social realities of Texas. Covid has made local organizing impossible but I have built a "proof of concept" with Kubernetes and Ceph. I figured it would be better to apply the loose work I've done for my project to Cloudy since Cloudy is much more established.

I am by no means an expert but if there is any specific issues/feature requests/etc that you'd like to develop I'd love to help.

Regards, Leena