Installing custom Apps on Cloudron

[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.

[scooke]

@Lanhild This is exactly what I'm talking about. Just to be clear, I'm not trying to fault that user or to try to shame them or anything... it's just an example of what will happen.

[Lanhild]

@scooke Completely get your point.

That's why I liked what @girish said:

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 [...]

What's necessary is to make it clear to users that no support from the team will or can be provided for a 3rd party app, that's what 3rd party implies, as well as potential risks and bugs.

It's the same with, e.g., a 3rd party PPA on ubuntu, a custom APK on Android, a cool application you just found on GitHub, etc.

I think distros like Ubuntu use the right words to explain this to users.

[scooke]

I think it is already clear. The user knows it is a custom app. It seems logical that Cloudron updates what it manages. The user is still unclear, and taking time away from other more directly-connected Cloudron help requests.

One issue is just how helpful the Cloudron team is! When I think of all the times I used an included piece of software in Yunohost or Caprover or what have you, ran into trouble, went to their forums and other onlines sources of help, asked a clearly worded, respectful question.... and then got no response, ever... the total 180 in attitude by users on this Forum and specifically the Cloudron Team is stupendous. They need to be saved from themselves! So, I think one way to ensure users understand that they shouldn't expect help, or at least priority, is to keep the custom install method not part of any official-sounding process. Anyone brave enough to try a custom install needs to go digging for it, to trawl the forums, to get help (and give it) from other Forums users, without making any complaint towards or about Cloudron.

OR, Cloudron should make a Priority Tier of help that automatically charges $$. Anyone on the Forum who signs up, and also tries out Custom apps, should include a payment method so that when (not if) they come looking for help they are charged automatically. That might cut down on ppl just trying stuff out, or ppl who think they are more apt then they really are., and not fill the Forum with their niche help requests.

While I'm ranting, lumping home servers, NUCs and Cloudflare usage in with this paid-tier might also help drive home that Cloudron's main use is, as the home page says, Create a fresh Ubuntu Jammy 22.04 x64 server and run these commands. I realize Cloudron itself suggests that home servers (behind arcane router options) and NUCs (often "protected" by Cloudflare) are options, but for the most part much of how it is described makes it clear that it is intended to be installed and run on a VPS.

Well, I know that door is opened already and there is a horde of Cloudflareons here, and homehosters... but this is not how I promote Cloudron.

[Kubernetes]

@girish What about a "Unsupported"-Label with an Disclaimer that needs to be Acknowledged by the user for each installation of an unsupported app?