Installing custom Apps on Cloudron

[timconsidine]

@Kubernetes ah yes, any customised start.sh should be contained already, thanks for the correction.

[timconsidine]

@Kubernetes would like to test or contribute but I am tied for a week, and you're clearly on a roll !
I'll catch up as soon as I can.

[Kubernetes]

I created a Repo in Cloudron GitLab to have the script maintained

[fbartels]

This sounds like a nice imitative.

I think I would piece this together a bit differently. Having a small bash script as the glue that holds it together is fine. But instead of installing the cloudron cli via npm I would just execute is as a docker container. This way you also have more control over versions and don't need to tell people to manually update the cloudron cli.

Instead of asking people to manually download the manifest and favicon, let them supply the url to the git repo of the app. Then you could do a local clone and get these files from the clone. This also opens up the possibility of building the app locally instead of using somebody elses (potentially untrusted) container image. For apps that should still be pulled instead of built you could include a text file with the address of the container instead of having to have your user copy it manually into a file.

The other benefit of putting some of your logic inside of a container is that your could there rely on better tooling instead of parsing yaml files with bash.

I have only had a quick glance at your script and the way it looked to me you need to have one configuration file per app (and also one copy of your script per app?), which will lead to a lot of duplication.

Edit: and for the approach with the surfer app you should make sure to tell people to create these files in a place that is not served to the internet. Else you may expose your API key to the public.

[Kubernetes]

@fbartels said in Installing custom Apps on Cloudron:

But instead of installing the cloudron cli via npm I would just execute is as a docker container.

Not sure if I get the point. How will we call the docker container (with cloudron cli) in that scenario?

Instead of asking people to manually download the manifest and favicon, let them supply the url to the git repo of the app. Then you could do a local clone and get these files from the clone.

I agree, this would help to make it easier.

This also opens up the possibility of building the app locally instead of using somebody elses (potentially untrusted) container image.

The reason why we started with this initiative was that there are people who are not able to build the app locally. People who know how to do that, do not need the discussed approach.

For apps that should still be pulled instead of built you could include a text file with the address of the container instead of having to have your user copy it manually into a file.

Good idea.

The other benefit of putting some of your logic inside of a container is that your could there rely on better tooling instead of parsing yaml files with bash.

In fact it is not really a yaml, it could also be named .txt - I just didn't want to call it .ini as we are with Linux

I have only had a quick glance at your script and the way it looked to me you need to have one configuration file per app (and also one copy of your script per app?), which will lead to a lot of duplication.

Yes, this is right and an issue.

Edit: and for the approach with the surfer app you should make sure to tell people to create these files in a place that is not served to the internet. Else you may expose your API key to the public.

Thanks for the hint, I did add this information to the README.

[fbartels]

@Kubernetes said in Installing custom Apps on Cloudron:

How will we call the docker container (with cloudron cli) in that scenario

You could use the following snippet in a function (but maybe use your own instead of fbartels/cloudron-cli, it certainly needs updating):

docker run \
        --rm -it \
        -u "$(id -u)":"$(id -g)" \
        -v /var/run/docker.sock:/var/run/docker.sock \
        -v "$(pwd)":/code/ \
       -w /code \
        fbartels/cloudron-cli:5.0.0 "$@"

Then you can just call my_function cloudron --help. The command runs in the same dir and with the same user id, as you would have run it on your local system.

@Kubernetes said in Installing custom Apps on Cloudron:

The reason why we started with this initiative was that there are people who are not able to build the app locally

Yes, but the question is "why cant they do that already?". Which piece of knowledge and ability are they missing exact? Wrong platform/os? Missing linux knowledge?

@Kubernetes said in Installing custom Apps on Cloudron:

I just didn't want to call it .ini as we are with Linux

There for sure are also ini files on Linux, but there are a lot of choices. My preferred one would be to call the file config.env and then you could simply source it. But there are probably thousands of ways.

[robi]

@fbartels said in Installing custom Apps on Cloudron:

My preferred one would be to call the file config.env and then you could simply source it.

I agree, that's my preferred choice too, it holds ENV vars

To make this work with an authe'd GUI, the existing Cloudron build service App can be easily modified to support this further.

It already knows to get the API key once you log in, the rest is invoking what the easy-install.sh script does. No Surfer App needed.

[girish]

@Kubernetes just an idea, but if your docker images are public, then you could maintain a version -> image map in an online file somewhere. With that people can skip the whole build step altogether. Of course, they need to trust you about the images but I doubt such people are going to code review your app package source..

[BrutalBirdie]

@Kubernetes That is also what I do for my Cloudron FoundryVTT package: =>
https://github.com/BrutalBirdie/cloudron-foundryvtt

I offer a public pre-build image and a little readme how to build it yourself.

[Kubernetes]

Yeah, I did it similar with the easy-installer script , too. I have put it into the cloudron package template repo ... i may archive the old app installer repo - as it is outdated already

[timconsidine]

The work of this approach is great.
Can't underestimate its importance.

Just thinking out loud, overcoming a user's reluctance/fear/unfamiliarity to use the terminal and execute commands is only really going to be solved by a GUI.
I wonder if that turns out to be the destination.

Equally, if a Cloudron user has successfully got to a terminal on their VPS and been able to execute the cloudron install script, maybe I'm wrong and installation by command line is going to be enough.
After all, it is expected that users can open Terminal or File Manager to adjust config or env files.

If we can get it to a 3 step process, maybe that's enough :

• install "base" or "shell" app from AppStore (e.g. Surfer or LAMP)
• open Terminal and execute wget https://zzzz.yyy/custom-app-install.sh && chmod +x custom-app-install.sh && ./custom-app-install.sh (copy & paste of course)
• close terminal and restart app

Maybe @staff can be persuaded to approve a CustomAppInstaller app in the AppStore which provides a GUI to this.

Again, just thinking out loud.

[timconsidine]

@Kubernetes doh! I missed the part in your repo where the temporary Surfer app can be uninstalled. That's neat !

[robi]

@timconsidine said in Installing custom Apps on Cloudron:

Maybe @staff can be persuaded to approve a CustomAppInstaller app in the AppStore which provides a GUI to this.

There's a FR thread for this here: https://forum.cloudron.io/topic/10987/cloudron-build-service-add-ability-to-to-install-custom-apps

In another thread @girish suggested an even easier way, creating a small modification to the App Store where one can do this.

[Lanhild]

I may have an idea for the easiest way to achieve this. (I don't know if it's been proposed before)

Instead of creating/modifying a dedicated Cloudron app, a simple change could be made to the app store: The ability to add custom sources files.

Just like apt or any other package manager has, we could have source files that contain;

• Links to valid git repositories with app package code
  

Each source files you added could also have applications that use private Docker images, so prompting the user if they want to add a custom registry credentials for this source file would be necessary.

This would then allow to list additional applications in the Cloudron app store that come from these source files, and tag/label them as Custom

You could install them just like officially packaged apps, update, backup, etc.

IMO, sources files would be the most user-friendly way to install custom apps as there'd be no need for the use of Cloudron CLI, as everything would be done through the UI

Let me know what you think about it.

[robi]

@Lanhild Good idea.

It would help to make a PR with the proposed changes to @staff have less questions and coding to do to make it work. That may speed things along.

You may have to ask for access to the repo where the code for it is.

[plusone-nick]

this is a huge feature addition
+1 on it being native

[scooke]

@Lanhild it's a nice idea for the end goal and user, but then the Cloudron team will invariably be drawn into trying to provide support for these non-Cloudron-built pieces. And as they are distracted from their own Cloudron-specific work, I think Cloudron itself would start suffering, leading to more troubleshooting and complaints, leading to Cloudron staff having to disavow all of this custom work and not provide support anymore, leading then to more users complaining about Cloudron, accusing Cloudron of "not caring", and voila, we have a downward spiral.

I think it is super that Cloudron even allows for the amount of customization it gives us, but hey, it's their work (which benefits us), not our playground.

[Lanhild]

@scooke I get your point, but not the first part. Why would Cloudron be responsible for custom applications people install on their Cloudron? It would be the same as today, other than the fact that there'd be an additional layer to download these custom applications.

What I mean is that, right now, people are and should be aware that there are potential risks in installing custom applications (which, by default, the team provides no support for and that is 100% logical).
This awareness wouldn't change, the difference would be that the actual task of installing the app is facilitated.

[BrutalBirdie]

@Lanhild said in Installing custom Apps on Cloudron:

the team provides no support for and that is 100% logical

What's logical and what people do is two different worlds

[girish]

I think if we can find a ux flow where it's clear that this is out of scope for the Cloudron team, then it would be great to have 3rd party apps. It needs a better messaging than 'unstable' because 3rd party doesn't mean unstable. We will brainstorm a bit on our side and get back on this.