Cloudron Forum

I believe that all related information is on the screenshot.
What I don't like about it - it's that there were no e-mail notification and no notification on that whatsoever!

on top of everything, Element X require livekit & jwt to work; if you are using OpenID connect - you have to use MAS, as Element X will not work otherwise (not now, nor ever).

Yeah, MAS jumped from all of the sudden from 0.2.something to 1.0 - very well... And that is all with 136 issues opened, including the issue when the user won't be created as it should.

I've ejected Synapse from Cloudron and run it independently - it is kind of working (if you don't mind get your hands dirty in the database), but if you don't need Element Calls - I can't see no real benefits.

Not sure if the question was anyhow directed on me, but I hope that rant might be of some use anyway

Apologies and correction.

Cloudron's functionality works just as intended. The problem is in docs in major sites and hence chatGPT as well (which I used to troubleshoot that).

All of the docs, except for NameCheap (thanks, guys!) says that the correct way to combine crt files - is just do cat .. > final.crt which lead to one problem:

-----END CERTIFICATE----------BEGIN CERTIFICATE-----

On the line 37, which, absolutely reasonably, brakes any SSL parser.

Correct way to join CRT files is:

cat STAR.*.crt > ssl-complete-bundle.crt && echo >> ssl-complete-bundle.crt && cat STAR.*.ca-bundle >> ssl-complete-bundle.crt

And you can check if it is valid than with

openssl x509 -noout -in ssl-complete-bundle.crt -checkhost test.`basename STAR.*.crt | sed -E 's/^STAR\.([^.]+(\.[^.]+)?)\.crt$/\1/'`

Guess, it might make sense to document it.

@joseph have the very same problem here.

openssl x509 -noout -in STAR.domain.com.crt -checkhost test.domain.com works on pure (aka 'leaf') CRT file, but fails on a bundle (cat STAR.*.crt STAR.*.ca-bundle > ssl-complete-bundle.crt) - with an intermediate certificate build-in.

And if I upload that pure / leaf certificate, then all apps that are not browsers fails with unable to verify the first certificate kind of error (that particular is from UpTime Kuma) - as an intermediate certificate is missing.

So, I would say that own wildcard certificate functionality is quite broken as of now on Cloudron.

Thanks. I'm fine with an occasional troubles that I will leave alone (after all it was working fine for a few years without any problems), but I was absolutely sure that all 'core' services are monitored thought.

Is there any chance to expect that anytime soon?

I can't think of a work-around solution for a turn-server external check...

Is there any way to have turn healtcheck implemented?

I realized my turn server has been hanging somehow weird with the following messages in the logs:

=> Generating turnserver.conf
=> Ensure permissions
=> Starting coturn
bind: Cannot assign requested address
Cannot bind local socket to addr: Invalid argument
bind: Cannot assign requested address
Cannot bind local socket to addr: Cannot assign requested address
bind: Cannot assign requested address
Cannot bind local socket to addr: Cannot assign requested address

+ I wasn't able to extract them from the web console - it returned zero (empty) log - that is the output that I've received via docker log command.

@ccfu I can not agree on deactivate - the purpose is very useful. I would rather have it working properly!

@nebulon I wish...

Guess I will end up removing it from the database, if it will be disturbing me too much

Regardless - thank you for the tool!!

Star based monitoring works!

I'm not using github stars, so I'm fine leaving with them - just one more question then: how do I remove a manually added entry?

@nebulon it's not that I'm using github automations, so rate limit is unlikely...

I understand the necessity for the logs though - that's why I asked how I can enable debug mode - to get them

Is there some way to enable debug mode to fetch the logs?

@nebulon looks like not...

@joseph apologies, I wish I had time for that

I can enable debug mode, but I can't see no configuration file - happy to follow some reasonable instructions to enable it (I can see debug on the code)

I've added https://github.com/element-hq/synapse manually for the monitoring at 1.120.2 and it picked up no new releases ever since (and the latest is v1.128!)

According to the logs, everything is synced Ok

Apr 26 22:35:48 releasebell/tasks run: start +1h
Apr 26 22:35:48 releasebell/tasks syncGithubStarredByUser: admin +4ms
Apr 26 22:35:49 releasebell/tasks syncGithubStarredByUser: found 1 starred repos +244ms
Apr 26 22:35:49 releasebell/tasks syncGithubStarredByUser: new projects: 0 outdated projects: 0 +4ms
Apr 26 22:35:49 releasebell/tasks syncReleasesByProject: [element-hq/synapse] type github_manual start sync releases, notifications are enabled. Last successful sync was at 2025-04-26T19:35:48.572Z +15ms
Apr 26 22:35:51 releasebell/tasks run: done. Next run in 3600s at Sat Apr 26 2025 21:35:51 GMT+0000 (Coordinated Universal Time) +6ms
Apr 26 22:35:51 releasebell/tasks syncReleasesByProject: [element-hq/synapse] found 0 new releases +2s
Apr 26 22:35:51 releasebell/tasks syncReleasesByProject: [element-hq/synapse] successfully synced +0ms

Could you please, help with that?

Could you please convert that thread into a request to remove 'Cloudron' from the mail templates as well as from translation files, please?

@girish my bad, you covered it all, it's just me who just got what you meant - apologies and thanks for keeping explaining.

@girish Ok. And could you please, answer on my initial question, regarding the actual lines that are replaced inside the template?

Like I've told, I'm not referring to 'Powered by Cloudron' - I'm referring to the lines you have in Weblate.

@girish , I'm not referring to 'Powered by Cloudron' line - I was referring to 'Cloudron' direct mention in the title of the mail, for example - and I can't see it's being anywhere in the template - that's why I asked for localization.

you can just remove the line from /home/yellowtent/box/src/mail_templates/*.ejs files

Guess they will be overwritten on every update, wouldn't they?

@girish understand on not a priority - makes perfect sense.
Where do I remove that from? Where are localized strings stored in deployed Cloudron instance?

Negative. Please, disregard what have been said earlier: OpenID from Cloudron could be used as is.

Happy to share my findings on setting up the service with @vladimir.d or whoever will be doing this configuration for everyone on Cloudron.