I think the install script needs improvement
-
The installation script for Cloudron is too simple and I dear to say not well written.
If it fails ie. is stopped, at any step, the installation is rendered incomplete and it requires the user to provide it a "fresh ubuntu installation" upon next run.
For my last Cloudron installs I have had to rip out functions, ie comment out or delete the lines in order for the installation to complete.
It should not be this way.The script should be idempotent. It should be able to run many times over without failing. It should just state that such and such step is complete or incomplete.
My suggestion:
All installation steps should be composed in an ansible playbook.
The shell script should download the latest ansible playbook and ensure that ansible is installed on the host machine. From here it should simply launch ansible with this playbook. The rest is magic.
The playbook itself is idempotent and can be run infinite amounts of time, without causing state issues. -
Yes, and while a total shift to ansible might be more than @staff have time for, a more modular step wise modification of the install script might do the trick. That way on any error the user can simple get a number to repeat the last step.
This might also require the undoing of the last failed step, so the next run can continue unimpeded.
If you're good with that, feel free to contribute a code pattern to get things started.
-
The Cloudron team has explained that this approach has been, thus far, the best way to deal with the numerous environments in which a user tries to install Cloudron. Any existing software that might not be suitably set up is almost guaranteed to cause some failure in the Cloudron. So, start fresh, each time.
FWIW, I've installed Cloudron several times on several different VPSes from different hosts going back several years, and have never run into the kind of problems you describe. (Well, waayyy back in the beginning I had to comment out an FS check ((ext4)), more to see if it would work, and it did.) Another time there was a problem, but it wasn't Cloudron, it was the VPS which came so barebones that it was missing some network things that I had to install on the server first. But, in installing Cloudron, it was Cloudron throwing errors, making it easy to think it was Cloudron's problem. It wasn't.
To be repetitive, there are so many different posts asking for help or saying Cloudron installation failed, and then the troubleshooting starts to reveal - an EoL OS like Ubuntu 16, and non-Debian OS, a host-caused misinstallation due to a custom image used, a home server (don't even get started on THAT- windows, mac, 100 flavours of linux, behind a router, inside a router, behind Cloudflare, not on a VM, on a VM made by VMware, on a VM made from VirtualBox, on a plain old desktop version of Ubuntu which already has 1000x variations of node, npm, yarn and who knows what else all installed by differing manangement software...), a server which already has variations of software on it (can people not read?? <Create a fresh Ubuntu Jammy 22.04 x64 server and run these commands>. FRESH. 22.04. server.) Anyone who follows this does not need to rip out, comment out, nor delete anything.
I've tried using Ansible... talk about ripping out, commenting out and deleting!! Compared to Ansible, Cloudron's installation is a marvel!! EDIT:(I took out "A final word..." because it sounded like I didn't want to discuss anymore, or that I thought the 'argument' was clear. Not at all. I'm just sharing my perspective and have no intention of trying to shut up others.
-
I doubt we will move to ansible or any other system but I think the request is still valid.
In practically all the installation fail problems, the issue is unbound/dns related. When we configure unbound, various things start failing. I have a task to try to see if we can get rid of unbound altogether at the system level and use it only for specific things Cloudron needs it for (RBL checks, DNS propagation checks etc). I think this will fix most of the problems.
-
I would start with just the package installations and then move on to shell tasks when that has been perfected. Installing packages are very simple tasks to achieve in Ansible.
The shell script cpuld at least have some shell code logic that evades the current race condition where it refuses to run a second time because packages it installed itself are already installed.
-
@makemrproper said in I think the install script needs improvement:
The shell script cpuld at least have some shell code logic that evades the current race condition where it refuses to run a second time because packages it installed itself are already installed.
How will it discern between a stalled fresh install (in which situation your suggestion makes sense) and an environment that is not fresh but the user has already installed sofware, with no guarantee that it was done correctly?
-
@scooke said in I think the install script needs improvement:
@makemrproper said in I think the install script needs improvement:
The shell script cpuld at least have some shell code logic that evades the current race condition where it refuses to run a second time because packages it installed itself are already installed.
How will it discern between a stalled fresh install (in which situation your suggestion makes sense) and an environment that is not fresh but the user has already installed sofware, with no guarantee that it was done correctly?
There are many ways you can write this in shell code.
Declare what minimum versions are needed and verify with apt that these are installed. Which by the way is precisely is what apt does for you and what ansible also does.Shell script logic, some functions with conditionals achieve this.
Write an array which contains all needed package versions and iterate through them verifying if this is installed or not. If yes great, continue.
-
@makemrproper Sounds cool. The same can be done in cases (and there are loads of posts across many a forum) where someone has two versions of node installed, but their system is only recognizing one them (and of course it's not the correct one)? The same scripts and shell code will read the system, determine if the correct version is needed, uninstall or negate all the others, fix the users shell, or .env, ... isn't this starting to sound like Cloudron is managing users systems rather than just installing and managing itself and what it installs?
