Cloudron Forum

I needed to comment out a number of lines in the site_settings.yml file before Discourse would finish starting up. Specifically, I commented out the following: users.min_username_length: min line and max line users.max_username_length: min and max basic.categories_topics: min and max After doing this, everything appears to be running smoothly!

@girish Setting [indexer] ISSUE_INDEXER_TYPE=db in app.ini solved the issue immediately. Thanks alot! Now I'm curious to know what db means in this context (but the urgency is gone ). Should the Cloudron package have db as ISSUE_INDEXER_TYPE out of the box, for example? Some Cloudron app config data got alot of legacy files from earlier versions, so sometimes it's hard to know what the true good defaults are.

@yusf thanks, fixed in latest package.

Thanks guys, I check out those resources provided

Disclosure here - https://matrix.org/blog/2021/09/13/vulnerability-disclosure-key-sharing We pushed out update to Element already. Please update asap.

@iamthefij alternately, if the ldap syncer could write the emails to some db field/file and bitwarden_rs can use that as an allow list that would also work.

@fbartels Thanks for the suggestion! Looks like that tool needs the master password every time it performs an action so no automation possible, but still good for periodical manual backups.

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)

@girish Yes. It's listening on 0.0.0.0:8080 and it's on a remote server as well, so localhost wouldn't work either way. Also, I don't know what happened but even though all tests failed I kept the webhook setting active and when time came for a real event and not a test event, it actually works: [image: 1613550848170-61d4b94d-dc85-4e26-b508-8b4310dbc9c8-bild.png] So, test deliveries don't work but that might be because of how the recieving webhook is set up, I don't know.

I was totally in the wrong here. I just looked at the wrong section it turned out Sorry for taking up your time.

@yusf OK, thanks, when you find time, feel free to reach on the support mailbox.

@yusf Do you see any error in the logs? That should tell us if you hit the same issue as @plusone-nick

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

@yusf Are backups failing by any chance. I wonder why there are multiple backups in a day. How often do you create backups? If it's one week backups from 17th Npv are expected. the ones which are slightly older are probably preserved for various reasons. One thing you can do is Backups -> Cleanup backup. Then in the same view, click on logs and it will tell you why each and every backup is preserved. If you paste the log, I can explain in a bit more detail.

The calendar in Kopano Groupware can be used in this way. Overbooking, auto accept/decline. The publication could be something implemented on top of our rest api.

@yusf I knew I'd seen some others so I went looking. I didn't find what I was looking for, but found these which look OK: https://www.classroombookings.com/ https://en.freetobook.com/index https://github.com/webkul/hotelcommerce

I have to do this for some other day - https://git.cloudron.io/cloudron/nodebb-app/-/issues/6

@nebulon said in Extra fields in LDAP: The phonenumber for Mattermost is one such use-case, but that can be also solved without custom fields. Assuming there might be a need for this in the future - what was the solution you thought of? Also, even if app's don't use the fields, just having the Cloudron User directory more fleshed out might be a good thing for reference sake.

@fbartels "Basic auth" is only what happens between the browser and the server. The server can verify a request that uses basic auth against any authentication back-end, including an LDAP server. I actually did something similar for the Transmission in my River app: as Transmission also uses basic-auth, the various mobile-apps & browser extension need it to work, so I had to accept it for them to work. This UI makes me wanna try to package a docker registry for cloudron... I'll have to dig deeper into how it works