Cloudron Forum

Cool, this is great, thanks! Even if it's not perfectly dynamic this will save me a lot of typing

Specifically wondering if there would be a programatic way to generate a list of application IDs and other information about the installs available in the platform. Even just a JSON feed would be pretty cool to keep a dynamically generated list of everything available.

Awesome, thanks!

An administrator should be able to reset a user's password on their behalf. The current ability to only send a password invite does not work well when attempting to integrate Cloudron with external systems that might need to sync a common set of credentials between the two. The Update User API call should be updated to allow a token with admin access to set the password.

You can have any number of domains, here is information on adding them https://cloudron.io/documentation/domains/. Once a domain is configured it becomes an optional location when installing an app. Let's Encrypt is setup automatically when you install an app in Cloudron.

FWIW switching to rsync fixed the original issue of this thread in my case. Figured I'd update here to let folks know.

@girish said in Toward a "Domain of One's Own":

In addition, when students logs into the Cloudron dashboard, they only see apps that they have access to.

Am I wrong that this is not how it currently works? When logged in as a regular user the Cloudron dashboard shows all installs on the server.

I want to think the hurdle of an admin needing to do the installing is something external tooling utilizing the API could accomplish. As long as the permissions thing is worked out properly. Scaling a Cloudron server for each student sounds pretty expensive to me so I'm definitely more interested in the first scenario if the friction can be removed.

Thanks, I'll try switching to rsync and see if that resolves it. The log seems pretty bare (I'm backing up to DO Spaces but I believe the failures were happening even with local filesystem). Will check back in if it persists.

I get emails fairly regularly with this message and I'm not sure where I would begin to troubleshoot.

{ stack: 'BackupsError: Backuptask crashed\n at /home/yellowtent/box/src/backups.js:487:29\n at f (/home/yellowtent/box/node_modules/once/once.js:25:25)\n at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:70:9)\n at emitOne (events.js:116:13)\n at ChildProcess.emit (events.js:211:7)\n at ChildProcess.kill (internal/child_process.js:395:12)\n at Timeout.<anonymous> (/home/yellowtent/box/src/backups.js:503:12)\n at ontimeout (timers.js:475:11)\n at tryOnTimeout (timers.js:310:5)\n at Timer.listOnTimeout (timers.js:270:5)',
name: 'BackupsError',
reason: 'internal error',
message: 'Backuptask crashed' }

Possibly a memory issue?

The licensing for Koken doesn't prevent an installer from being created for it and it's available on many hosting platforms today already. While obviously open-source is an ideal, I'd hope it's not a limiting requirement for anything that goes into the available apps. Koken is a great piece of software and sure, add the alternatives in there as well and let the user decide what they want to run.

Standard users can't generate a token to make that API call though, right?

@stoccafisso That's a good point. It looks like we'd need to add 'password' as an option to the Update user call as well

@girish Awesome, works perfectly! Thanks for the super fast turnaround!

@girish Taking a password via the API to bypass the verification process would work perfectly.

I'm looking at generating user accounts externally through the API. It looks like even though you can prevent the invite from being sent, the user does eventually have to go to the invite URL and enter a password, is that right? I'm hoping to not have to expose the user to the Cloudron admin interface and rather have them interact directly with the external application. Could I POST data to the invite page directly to complete the creation of the user account?

Late responding but thanks so much for the fix @girish !

@girish Sure thing, it's now enabled! I appreciate you taking a look. The "read-only filesystem" part of the error made me think something on the disk but other installs in the same server are running fine and there's no problem with disk space (I haven't even begun to look into why backups weren't happening either but figured I'd tackle that after diagnosing the immediate issue).

Woke up to a hosed install. Log mentions a read-only file system

https://pastebin.com/WS23VrRr

Any ideas? Unfortunately it looks like backups weren't being done on this install for me to restore to.