The Cloudron User Repository - CUR

The what?
CUR is deviated from AUR - Arch User Repository

AUR is awesome and makes it very easy for Arch Linux Users to install software from other users.

In similar fashion I would love such a feature in Cloudron.
I packaged:

• Greenlight
• Valheim Dedicated Server
• FiveM GTA V Multiplayer Server

From my 3 packaged apps only Greenlight made it into the app-store. Yet!
Why did Valheim and FiveM did not make it?
Simply put, the lack of users testing the app and reporting back.

Does Cloudron need an CUR?

Arch Linux is loved for the AUR and I am sure that CUR would also have this effect for Cloudron.
I believe many users do not test apps since they are used to the app-store and even the thought of touching the shell to install a community app with the cloudron-cli is very spooky to the targeted end-user of cloudron.
Especially on productive systems doing such thing is a no-go, since you want stable prod which does not fail you.

Now imagine a CUR.
With a simple click in the setting you can enable the CUR and can install a community app to test and give feedback.

This would decrease the barrier for end-users and @appdev(s).

This could also decrease work for maintaining apps if they stay community apps and are not suited for the general Cloudron app-store.
CUR should be excluded from Cloudron Support for obvious reasons.

I would love to get some thoughts on this.

Cheers,
Elias

(ps: I am aware of many side effects of AUR/CUR and stale unmaintained packages, but AUR still rocks )

@uiguy okay lets start

@uiguy said in How to Take Cloudron Even Further:

I appreciate that there is the package maintenance aspect, but from what I have seen about the support structure, there seem to only be 2/3 guys supporting the maintenance... how can this be enough to support an entire app ecosystem

Everyone having the APP DEV to their name is a Cloudron App Developer, so in extend a supporter of the ecosystem.
For example I am the maintenance guy of the Greenlight app.
My job circles around Greenlight and BigBlueButton as well. So its in my own best interest to provide updates which just works without any hustle since I have a lot of Greenlights running for customers and doing something that does NOT work effects my own work

Another example would be Dolibarr from @erics who is a developer of Dolibarr.

@uiguy said in How to Take Cloudron Even Further:

I am battling to see why we would rely on cloudron and the associated app store is quite limited as opposed to something like running docker direct?

Reliability and Repeatable.
I have restored multible Cloudrons from full backups, single app backups and literally never had it fail me.
Having the option to roll back to the previous version with 1-Click. What a dream!
Not to mention the package / backup policy to minimize the backup footprint.
For example my self maintained Valheim Gameserver App where we discuss about what is backup worthy.

Having the option to sync Cloudron to an external LDAP also just adds another cherry on top.
Having multible Cloudrons synced to a central LDAP. Sweet.
User und Customer management from 1 place deployed to X Servers with Groups and Permissions.

@uiguy said in How to Take Cloudron Even Further:

I guess, what I am in need of, is some education as to why I would advise we invest in cloudron when we could simply deploy docker with something like portainer and watchtower for package maintenance?

I don't mean to sound negative at all, but I simply want to understand what the value proposition is, especially if I have to compare the available packages on docker vs cloudron?

That is the best part, you don't have to!
You can make your own app, you are NOT limited.
The so called gilded cage with Cloudron is the knowledge you wish to have about the system.
Gitlab of every app https://git.cloudron.io/cloudron

There is more which I could mention, but these are just some thoughts of mine.
Check out this topic where people tell what are your favourite things features about cloudron

https://github.com/ViViDboarder/vaultwarden_ldap

https://github.com/dani-garcia/vaultwarden/wiki/Syncing-users-from-LDAP

Since the Vaultwarden app right now has its own user management it would be nice to also have the LDAP functionality here as well.

Some Ground Rules I made myself:

USE GIT!
Nothing is more frustrating then having a kinda working state, tinkering more, have a completely broken state again and then don't remember what changes you done.

/app/code - the application binary

Everything binary which shall not be changed and belongs to the application belongs in /app/code and can mostly be done in the Dockerfile.

If parts of the application require on premise files, like cache or temporary files which need to have read-write access it should go in either /tmp or /run (This can not be tested in the Dockerfile since it's at runtime).

/app/data - The userdata

Everything that is backup worthy belongs into /app/data for example a config file which the application uses with the users configuration.

Debugging and Testing

If something needs to be done while runtime it can be hard to debug?
Kinda.
If your first deployment of the app fails, don't run back into your editor and tinker around.
Put the app in recovery mode and then start the application in recovery mode to see which parts fail.

You can tinker around in recovery mode and try to get it working.
BUT! With each step you fix in recovery mode it will get harder to backtrace all the fixes you done.
Each fix should be noted down or coded in the start script for the application.
Don't run yourself into a rabbit hole with 10+ fixes and then restart the app to then lose all those fixes again.

Being Stuck

Don't worry, it's normal.
Take a break, get 5-10 Minutes of fresh air for each 1 Hour of coding.

Don't be afraid to ask questions.
If you are packaging an app you can create a forum post and 'blog' your progress and struggles.
There are many users here who will chime in and give useful advise.

A Copy-Cat is bad!
Really? No.
Take a look at other apps and how they got packaged.
Maybe a solution for your problem is in one of the other apps.
If something is working and can be reused, go for it.

https://store.steampowered.com/app/892970/Valheim/

This game got recently released on steam and hit quite the trend.

https://steamdb.info/app/892970/graphs/

Having this server as an app would be nice.

And the work is already done!

https://git.cloudron.io/BrutalBirdie/valheim-gameserver-app

Needs some fine work with doc, screenshots and all.

But it's live and running at https://valheim.deadsec.net/

@jdaviescoates Not directly
I am not hired by Cloudron but working with them very close.

@privsec said in Admin and support question:

I wish there was a handy video series or something on how to package an app for cloudron

Uhmm not from the staff team but from appdev team by @fbartels

Youtube Video

@scooke

I will try to make it very short and understandable
Example from Greenlight => https://git.cloudron.io/cloudron/greenlight-app

git clone ssh://git@git.cloudron.io:6000/cloudron/greenlight-app.git
cd greenlight-app
docker build --file Dockerfile --target dr.cloudron.dev/org.bigbluebutton.greenlight.cloudronapp:1.0.20 .
docker push dr.cloudron.dev/org.bigbluebutton.greenlight.cloudronapp:1.0.20

Now if you view your Cloudron Docker Registry you should see your pushed docker image.

In this screenshot you can see docker images build by cloudron build by the cloudron build service with automated tags, that's why they seem a bit cryptic.

Now make sure you have setup your docker registry to be used in your Cloudron Server.
https://my.domain.tld/#/settings => Private Docker Registry

Now you should be able to install:

cloudron install --location test --image dr.cloudron.dev/org.bigbluebutton.greenlight.cloudronapp:1.0.20

App is being installed.

 => Queued
 => Registering subdomains
 => Registering location: test.cloudron.dev.......
 => Downloading image ..
 => Creating container
 => Waiting for DNS propagation ...
 => Wait for health check .......................

App is installed.

Cheers

Explaining some stuff you asked.

IF SO, then at what point do I push all this my Cloudron's Docker registry??? After the clone? Before the Build? After the Build? After the Install? And, regardless of the answer to that, once I've pushed the image to my own Docker repository... what's the point? It seems like all the work is done on the Ubuntu VM, in the cloned repository. And to then update... I need to pull from @nj's original Github repository, right?? To anyone brave enough to try to help me, thank you.

I hope my confusion is clear! I'm asking all this before doing anything else other than the initial clone from @nj's Github repository so that I understand it all well and can avoid missing some crucial step

You cant push / publish anything if you don't build it first.

what's the point

well.. your cloudron server can't just download the docker image from your local computer.

1. Community behind Cloudron (Devs / Forum / Community)
2. click restore / backups ! reliable backups !
3. LDAP Integration

Also who is the Cloudron "Team"?
Yes there is the "Staff" @staff @girish @nebulon and myself.
(btw. I do not have admin permissions here I just help out where I can since I work with Cloudron every day)

BUT! Big BUT imho the @appdev guys and every active cloudron user here in the forum is part of the "Team".
(edit: Sorry! @translator you guys are equally important! )

As expressed before:
https://forum.cloudron.io/topic/4594/how-to-take-cloudron-even-further/9

I believe the Community (you guys!) behind Cloudron is part of the Team.
Why else would everything be discussed and displayed so open here

I love posting my own mistakes and point out issues of Cloudron it self even tho I carry the 'staff' badge since I strongly believe this only shows you guys, that we care and are open to errors.
Since ignoring and hiding them does not improve them.

https://forum.cloudron.io/topic/6529/shooting-a-cloudron-server-right-in-the-brain-i-deleted-appsdata-and-boxdata-by-accident

@LoudLemur You have to take care of the community groups.
Only the members of each community should have access to their apps.
Cloudron can do this, no problem.

@LoudLemur this... is exactly one of the use-cases

I run a bigger community Cloudron Server for approx: 20 small communities.
They share one instance, pay the premium together and share the resources.

Each has their own domain, forum, teamspeak, Mail yada yada yada.
Each community has their cloudron group and users.
There is a even a "marketplace" RocketChat where all communities intertwine to share their knowledge and resources.

Socialist Hosting you might call it? xD

@jayonrails Hello

https://docs.cloudron.io/networking/#ipv6

You have to enable it

Could not reproduce at all.
very strange. Maybe @privsec needs to share the exact steps to this issue.

Maybe to reproduce this:

1. Correct Username + Broken Password
2. Same Username + Fixed Password
3. Still no login needed?

I will try this out.

@jdaviescoates can you please share the output of

docker images

?

@nebulon everyone loves a good pizza it will always be missed.

Maybe @nebulon can share some insight I also can't find it in the app store.

@staff
@nebulon you remember? I had the same issue with multiple Cloudron servers.

Okay, check if your Cloudron is still running Ubuntu 18.X.
If so check the box.service for errors, if there is an error with the note of:

Jan 09 17:15:00 ubuntu-2gb-fsn1-2 systemd[1]: Reload failed for Cloudron Admin.
Jan 09 17:15:03 ubuntu-2gb-fsn1-2 sudo[30793]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 09 17:15:04 ubuntu-2gb-fsn1-2 systemd[1]: Reloading Cloudron Admin.
Jan 09 17:15:04 ubuntu-2gb-fsn1-2 sudo[30793]: pam_unix(sudo:session): session closed for user root
Jan 09 17:15:09 ubuntu-2gb-fsn1-2 systemd[30858]: box.service: Failed to execute command: No such file or directory
Jan 09 17:15:09 ubuntu-2gb-fsn1-2 systemd[30858]: box.service: Failed at step EXEC spawning /usr/bin/kill: No such file or directory
Jan 09 17:15:09 ubuntu-2gb-fsn1-2 systemd[1]: box.service: Control process exited, code=exited status=203
Jan 09 17:15:09 ubuntu-2gb-fsn1-2 systemd[1]: Reload failed for Cloudron Admin.

On Ubuntu 18 it seems there is no /usr/bin/kill just /bin/kill then also check your /home/yellowtent/platformdata/CRON_SEED
The first int is the hour of the day.
Mine was 16:8 with the 1 hour diff of wrong timezone this matched up to the box crash.

Also please check if the renew log has anything inside, for me it was total empty.

So to everyone having this issue, please report if you are using Ubuntu 18 and if so your box.service has the same error.

@humptydumpty
Left a heart and like on the PR to show the support