@girish said in Trying to configure element with custom background:

{
"default_server_config": {
"m.homeserver": {
"base_url": "https://matrix.cloudron.work",
"server_name": "cloudron.work"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
},
"disable_custom_urls": true,
"disable_guests": true,
"disable_login_language_selector": false,
"disable_3pid_login": true,
"brand": "Riot",
"integrations_ui_url": "https://scalar.vector.im/",
"integrations_rest_url": "https://scalar.vector.im/api",
"integrations_widgets_urls": [
"https://scalar.vector.im/_matrix/integrations/v1",
"https://scalar.vector.im/api",
"https://scalar-staging.vector.im/_matrix/integrations/v1",
"https://scalar-staging.vector.im/api",
"https://scalar-staging.riot.im/scalar/api"
],
"bug_report_endpoint_url": "https://riot.im/bugreports/submit",
"defaultCountryCode": "DE",
"showLabsSettings": false,
"features": {
"feature_pinning": "labs",
"feature_custom_status": "labs",
"feature_custom_tags": "labs",
"feature_state_counters": "labs"
},
"default_federate": true,
"default_theme": "light",
"roomDirectory": {
"servers": [
"matrix.org"
]
},
"branding": {
"welcomeBackgroundUrl": "https://chat.swirlon.app/custom/background.png",
"authHeaderLogoUrl": "https://chat.swirlon.app/custom/header.png"
},
"piwik": false,
"enable_presence_by_hs_url": {
"https://matrix.org": false,
"https://matrix-client.matrix.org": false
},
"settingDefaults": {
"breadcrumbs": true
},
"jitsi": {
"preferredDomain": "jitsi.riot.im"
}
}

Oh my gosh thank you so much!!

Hi @girish, thanks for getting back to this. I have indeed figured out how to make this work.

Add a user as described before or use the synapse API:

@stantropics said in matrix / element user management:

/bin/matrix-synapse-register-user <path to homeserver.yaml> http://localhost:8008

If you are having problems setting a password I figured out it is not a good idea to manipulate the database, instead use the synapse API.

Until this point manually created users cannot login, you need to chage the config in homeserver.yaml as follows:

password_config: enabled: true localdb_enabled: true

localdb_enabled is false by default. Change it to true and manually added users can login.

@nebulon Yes, I have.

It looks like this to me.

ba1c540a-d551-4941-aba9-515457ecf4cb-image.png

@girish said in Can't upgrade Matrix server:

If you go to Settings -> Check for updates, and then come back to matrix and try to upgrade, does it work?

Derp, that's worked. 🤦 Thanks.

App Title and Version Matrix Synapse 1.33.1 App ID f4bb6a47-bbf6-4a35-b25a-01bee8462969 Package Version org.matrix.synapse@1.23.1 Last Updated Yesterday

There's a post about bridges from 2017 that outlines the general approaches bridges can take. The matrix-puppet-bridge project mentioned in that post now points to two other efforts Sorunome's mx-puppet-*, and tulir's mautrix-*, both of which feature in the matrix-docker-ansible project mentioned above.

It seems all Matrix plugins/bots/bridges/etc connect through the network as Application Services which (in Synapse) is configured manually by setting homeserver.yaml/registration.yaml to include authentication tokens used by the app to authorize its connection to the homeserver. This is part of what the ansible project does.

I think that ansible project is probably the best bet -- at least as a source of truth even if we don't end up using it directly, though extracting usable knowledge about correct configuration from it is not trivial. It has an faq.

I did some exploration, tracing the discord bridge's registration.yaml and noted the configuration dependency path through the playbook. I'm only mildly familiar with both ansible & matrix, but I think this helped me get a clearer picture of the configuration required to set it up; perhaps it will also help someone else:

global secret defined discord appservice token is derived token used to build discord registration.yaml registration.yaml file saved to disk at a location defined here discord registration.yaml added to list to mount into synapse container, and added to a list to configure synapse the list of registration yaml files is finally expanded into homeserver.yaml to be used by synapse

Also:

The discord bridge is configured in this config.yaml template, but it's not clear to me how it gets the appservice token to authenticate itself with the homeserver. The main tasks executed to install the bridge include downloading the bridge's docker image and installing a systemd service file that runs it.

The main issue I see with running the playbook on a Cloudron system is that it expects to be run as root on the base server. E.g. by default it creates docker containers, opens firewalls, sets systemd services etc. I don't think using it blind is a good idea and would almost certainly run into conflicts with Cloudron.

But lets say we could disable the problematic features, and use it to define and manage the bridge containers -- you still have the issue of getting the app service tokens into Cloudron-managed-Synapse's config.

@ericdrgn Thank you, you were right, I skipped this step.

Correct me if I am wrong but I think the Identity server is just a lookup service for contacts and lends itself to centralization for discovery purposes.

I guess https://github.com/matrix-org/sydent is the reference implementation but we don't have it on Cloudron yet.

Have you tried pressing try again? Wouldnt it be better to just create Cloudron accounts for your users? You can limit their access using groups on Cloudron level.

@atrilahiji so the apps can be installed on any domain really but for the user/channel handles to work in federation, the base domain (in your example domain.com) needs to provide information where to find the backend servers. That information is stored in a well known location.

We've just added those cases in the domain configuration directly, to avoid users having to edit text files in specific URL paths, which can be error prone.

@martin you can open the HTML file in the file browser app or via SSH and edit it. At least for me, it appears to persist across updates.

@atrilahiji @ericdrgn I started working on this yesterday and have similar questions.

In my case I just opened 3478 TCP & UDP on inbound traffic (on a VPC in AWS) and two users on the Cloudron could then make video calls - on Nextcloud Talk and Kopano Meet.

Monitoring the STUN/TURN logs going via the Services page, I could see a few 401s thrown before connection, but I'm not sure how to read what is happenining at this stage.

Do I need to open up 5349, as well, as indicated in the post above?

Yes, they’re all separate servers. But they each need their own port into the synapse server.

My suggestion is to leave some extra ports open instead of trying to assemble an app with all/most/some of the appservices.

This way we can integrate appservices today rather than dreaming about 20 maintained ones sometime in the future, if ever. (Wouldn’t blame anyone for not trying to maintain 20 wildly different appservices since they’re all very fluid pieces of software)

@yusf said in Google suspended Element in Play Store:

Calls and texts are literally pushed though.

For the 10% of important people still using them. 90% of notifications to me are unnecessary, no matter how much I try to whack them with settings.

@girish Of course, makes sense now. Should be fairly easy for everyone moving forward.

@msbt hmm you are right and I was wrong! 😓 I'll test if it works and report back 🙂

EDIT: Okay it works but only for new accounts (at first login with LDAP or local accounts).
The part in my homeserver.yaml looks like this:

auto_join_rooms: - '#discuss:yourdomain.com' - '#feedback:yourdomain.com' - '#help:yourdomain.com' - '#info:yourdomain.com'

@nebulon said in Question regarding setting up sydent as an identity server:

.
Ok, yes I haven't installed it via cloudron.
Thank you for the reply!

@yusf said in Changes in 1.25.0:

@girish They sre apparently changing the default to allowing custom usernames. This is terrible for me but it might also be undesired behavior within the general Cloudron experience.

localpart_template: "{{ user.preferred_username }}"

The above setting activated is responsible for retaining the previous behavior, iirc.

It seems that I've cried wolf since when setting up a new test user, no prompt was given to med when signing it in to the LDAP-enabled Matrix server with Element. Good!

@sebgg give this a read - i had the same problem and installing the element app and then deleting it might have fixed the ssl issue that might have caused the federation to fail.

https://forum.cloudron.io/topic/3974/help-making-federation-work/4?_=1610652549494

BTW, make sure to install matrix first, then element.

IIRC, the fix to this was to get federation working properly. https://docs.cloudron.io/apps/synapse/#step-3-federation

This is something you have to configure in the homeserver config file. 3pid (third party ids) in matrix can be email and MSISDN (phone numbers).

From what I can tell, you have to first setup a msisdn delegate and also set disable_msisdn_registration to false i guess.

I haven't found any docs on how what this msisdn delegate is though.

@girish Awesome thank you it works like a charm. Marking as solved.

RSS bots typically polls every 15, 30 or 60 minutes, or daily.

Default integrations are not a good experience at all currently. I can recommend maubot for RSS integration.

@msbt I have upped the memory to 2GB and since, this error : Oct 08 15:22:37 /app/pkg/start.sh: line 82: 101 Killed gosu cloudron:cloudron python3 -m synapse.app.homeserver --config-path /app/data/configs/homeserver.yaml

is completely gone.

But I'm still stuck at the same : even joining little rooms does not work, or works "randomly" ?

I just searched cloudron on the public matrix server, found it, joined just fine !

@yusf Fixed in the latest version.

And this issue seemingly tracks non-recaptcha support.

@girish
So i did actually set it to zero before and commented out the nginx file path.
So that killed it. IN THE PAST

But setting the upload to 0MB in the config and restarted.

It actually worked. Wow!

Thanks for having a functioning forum and the speedy response!

Not sure if this is related but in the logs for Surfer, which I have as a redirect for the root domain, I am getting a 404 for the matrix .well-known constantly.

GET /.well-known/matrix/client 404 1.083 ms - 328

Were you ever able to look into this @girish?