FWIW, I just installed all of this and tested it. Works great, instructions are clear. The yaml edits referenced by @msbt were quite helpful on the external-registration side.
Look forward to the eventual Jitsi package.
@girish Will do. It's actually not the first time I've run into the problem and a re-fresh of the API credentials solved the problem, although this is the first time I specifically observed that it was a 500 error vs. a 401.
This isn't so much a problem I need help with, but rather sharing something I didn't immediately find in a site search. I fixed my own problem, so now it's a suggestion.
I experienced a certificate error for the domain upon which my Cloudron control panel happily resides. No amount of irritable gesticulating could make it work -- I'd try to force certificate renewals only to see the control panel go offline and prove unable to connect. Logs weren't especially useful, either. I had to reboot the server from the shell to make things work again.
When I tried updating one specific app and it gave me a 500 error on the Digital Ocean side, it occurred to me that the API credentials must have expired. Which, as it happens, proved to be the case. I generated a new set, added it, and viola! life is good.
I wonder if we can have a better way of uncovering expired DNS API connections? Perhaps a check before a certificate upgrade that flags a plain-English error?
I'm trying to edit a specific user but no matter what I do, including trying to grant read or executeFunctions privileges to the user ID in
env | grep MONGO
I get the same response:
Error: not authorized on XXX to execute command ...
Is there a magic trick for actually querying the Rocket.Chat database from the Terminal that's not obvious to me?
A bit of thread necro, but I had the same problem. It appears that NodeBB is correctly configured, BUT in the Cloudron portal, by default, the "custom mailbox name" flag in the advanced app configuration settings is set to off. Thus, the email credentials correctly entered into NodeBB led to an account that, by default, was deactivated in Cloudron's mail server.
For others who stumble here:
Problem solved, although whether it immediately resolved or whether it fixed when I rebooted Cloudron to install security updates about three seconds later, well ....