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 )

@privsec
You visit a website:

1. Figure out how to decline all but essential cookies (disgusting anti pattern)
2. Close the support widget / live chat (bot) asking if I need help
3. Stop the auto-playing video (thanks Firefox you can block this)
4. Close the “subscribe to our newsletter” pop-up / contact us pop-up
5. Try and remember why I came here in the first place
6. A browser message asking if you’ll accept push notifications
7. Another asking if you’re willing to share your location
8. A banner suggesting you download the iPhone/Android app
9. An NPS survey asking you to rate the site.

just to name a few. . .
Does this sound familiar to you?
Please stop building sites like that.
If I only encounter 3 of these above items, I leave the page immediately.

@andreasdueren

For everyone interested we (we as in, my company and me) also offer Cloudron hosting as as a service.
So I can't reveal my whole hand so please be understanding

But what you are asking about is pretty simple:

Create a user with sudo permissions and add your ssh public key to that user (don't lose the password for that user since you will need it for sudo)

I also disable all ssh access with password, since this only opens the window for brute force attempts

Depends on the lock down wanted, you can also disable the root login via /etc/passwd by setting the login shell to /sbin/nologin looks something like this:

root:x:0:0:root:/root:/sbin/nologin

Then, even if you try a sudo su - you get this:

This account is currently not available.

But since you can edit the /etc/passwd with sudo access (unless you lock down the system even further) this can be a bit snake oily.

There is much more going on in my servers, but since we deploy everything via. Ansible I don't need to keep track of ever single detail, since its infrastructure as a code, I can just read up.
Login tracking, Log Tracking, Monitoring yada yada yada.

If a system farts, I get a message.

I hope this shares some insights.
A step by step guide on how to lock down the root user would simply be me copy pasting google searches.
When it's about Linux security you can do sooooo much: https://wiki.archlinux.org/title/security
there is also a good section on "restricting root"

EDIT:

Maybe I can do a step by step guide in the forum when I got some spare time.
But right now its a bit late and I am lazy

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

TL;DR

Create an app password in Nextcloud and use that.

Below is a more in detail explanation of the problem and the solution.

Requirements

You have:

• an external Nextcloud with the social login app using Cloudron OpenID
  • (How to setup an external Nextcloud with Cloudron OpenID login)
• within that Nextcloud the calendar app
• an urge to use the calendar in your favorite Client e.g. Thunderbird, mobile phone google calendar

The predicament explained.

Since CalDav needs authentication (username and password) you would use that. Easy.
But now, since we login with Cloudron via. OpenID the User in Nextcloud has no "password" and can also not be set.

So what to do?

Get into your Nextcloud and copy your internal calendar url:
Step 1 - click your calendar

Step 2 - share your calendar / view the calendar sharing information

Step 3 - Copy the internal link

Link should look something like this: https://YOUR.DOMAIN.TLD/remote.php/dav/calendars/my.DOMAIN.tld-USER.NAME/hackradt/ please note that hackradt is the name of the calendar.

Save this into a notepad, you will need it later.

Get credentials for your User.
Like above explained our User has no password, but we can set an App password!
Step 1 - click your user profile icon (top right)

Step 2 - click "personal settings" (in the dropdown menu)

Step 3- click "security" (left side)

In the bottom of that page you got "Devices & sessions".
Enter a new app name, I choose "SyncMyDav"

Click "Create new app password"
Note down the Username and Password and be 100% sure to click Done - if you forget the Done part it will not work!

Now you can use these credentials and the URL to configure your Thunderbird or DAVx⁵ for your Android phone.

Finally you can use your external Nextcloud with your Cloudron login, with en extra app password for your calendar.

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

7 days recap after applying your rules.
I believe not one spam mail has hit my spam folder or inbox so far.
normally I'd get ~20x+ spam mails a day since my Inbox also redirects my old legacy mailboxes from web.de which have been leaked and abused over and over again.

I must say, this feels very good.

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

@visamp
With Hetzner, try to gauge your Cloudron project.
How much will happen on that instance? Will you start small and grow or do you already have an app stack in mind?

Many customers of mine want to start small, so shared vCPU and CX22 which can be scaled up as needed.
If at some point the normal scaling comes to a threshold where a dedicated server is less expensive then a Cloud server we switch to that.
The Cloudon backup function makes it very easy to fully migrate between servers and providers (not needed when upscaling).

Just one thing to keep in mind! IP reputation for Mail!
If you have to migrate from Cloud to dedicated Hardware, do so with some time ahead since almost all IPv4 addresses have been used before and have a "bad" reputation.

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

@infogulch said in My Kutt was hacked! How? Check yours!!:

maybe it deserves to be highlighted more prominently in the install notes, or the default adjusted.

The Problem is you need to have registration enabled by default, because otherwise you can't sign up on the first run.

Already added a PR for a post install note.
https://git.cloudron.io/cloudron/kutt-app/-/merge_requests/1

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

Update - @nj thanks for the repo
https://github.com/njsubedi/cloudron-keycloak/pull/9

Upgraded from 20.0.3.

Looks good and working so far.

Adding to that.
Cloudron can be your "bastion" host with the OpenVPN app.

One recent example I setup for a customer.
He has an ERP system and wanted to use Metabase for some custom views / exports.
So here we go, setup the firewall to allow this one Cloudron to access the DB port.
Setup the DB to only allow external connections from Cloudrons public IP.
Install Metabase on Cloudron setup everything, done.
Where is the OpenVPN part?

Well he has developers who also wanted a live connection for fast db dumps.
Now they can enable OpenVPN to BE the Public Cloudron IP and just dump it.

Also yes, the external connection is only allowed via. specific users with specific DB read-only access.
Don't want people accessing the DB anymore? Stop the OpenVPN app for everyone.
Only want specific users to access OpenVPN? Cloudron / LDAP User Management.

The list grows

Please check your Cloudron Services, especially the postgresql Service, since the N8N App uses postgresql.
For a good analysis the following is needed.

• Output of the following command on your root server cloudron-support --troubleshoot
• The app log
• The postgresql service log
• The /home/yellowtent/platformdata/logs/box.log

Without that I can only ponder my orb.

I have multiple private registries.
Several Gitlab instances which function as docker registries, Cloudron Registry apps and so on.
The possibility to configure one is limiting and requires reconfiguration if a registry is changed or added.

One Example:
A custom app is being developed in Gitlab and this registry is configured in Cloudron.
Now an Docker Registry app is installed on the instance as well for fast testing with the Cloudron Build Service.
With the limitation to one private registry the configuration needs to be changed from an admin for the whole server.