@Sydney , thank you very much, indeed!
I really hope an app will make to Cloudron sooner, rather than later!
@Sydney , thank you very much, indeed!
I really hope an app will make to Cloudron sooner, rather than later!
I'm sorry, but:
Each conference will be launched within a container.
Sounds like a nice marketing wording for what's happening already for any docker-ized app. Every docker-ized app launch it's context within a container.
And I seriously doubt that for every call they deploy separate container and kill it afterwards - especially on Kubernetes, that would make calls setup extremely slow.
@robi hope so; and what are the 'homeserver caveats' you mean?
@robi you got to build it first, yep; going to follow that direction soon
I understand the rationale, thanks.
But the current decision have the following disadvantages, from what I see:
What we discuss calls delegation in Synapse terminology. It feels like extra feature for me and I really can't see reason to keep in on Cloudron, at least not with current setup.
Just in case - I know how to make things working for me, so I would be just fine with things as is, but I believe it's wrong from the logical perspective.
Are you able to login without 2fa
yep - by setting up temporary password with cloudron cli tool
Note that the ldap connector does not sync with a cron job, you have to press the sync button manually.
Not valid - as otherwise I wouldn't be able to login with temporary password - user wouldn't exist.
Manual sync - yes, sure. My logins worked up till I setup 2FA on admin on master server.
What about https://github.com/element-hq/element-call instead?
@avatar1024 said in Jitsi - Package Updates:
Indeed! Jitsi seems like it's gone sour a bit.
OpenTalk architecture doesn't feel any easier (https://gitlab.opencode.de/opentalk), nor OpenTalk provides mobile app.
I ended up running Jitsi on a bare (virtual) server - it works quite well, you just have to consider the whole Linux server as your Docker and avoid touching it as much as you can.
Keycloack - is quite a behemoth on itself
Apologies, any updates on that?
btw, the issue might be with new domains - publicsuffix2 never claimed it has full up to date database and it seem to be not updated for quite a while - so that might be the reason why it started failing just recently and on some occasions.
Even so, I can't see reason to cut sub-domain - everything works just fine.
Ok, let me make shortcut:
the following line:
server_name=$(python -c "from publicsuffix2 import get_sld; print(get_sld('${CLOUDRON_APP_DOMAIN}'));")
at Dockerfile introduced by Girish 3 years ago looks like a logical error for me.
I can see no reason to cut 'sub-domain' from 'sub-domain.domain.co' since it works just fine being installed on 'sub-domain.domain.co', if you revert / fix homeserver.yaml to contain FQDN.
Unfortunately, it's not the first time I submit bug report which is almost ignored or, at least, get no noticeable attention, so I don't expect this one will be fixed as well.
I have a workaround that works and that I shared with anyone interested: manually edit homeserver.yaml before launching the server and add well-known location. Hope that will be of some use.
@jdaviescoates said in Domain misconfiguration:
@girish said in Domain misconfiguration:
an app has to be installed on mydomain.com for the well-known to be served
He just meant "an app", not Synapse. Can literally be any app. But an app needs to be installed on
primarydomain.coop
for well-known to work, as per the docs.
I don't know what was meant, but even if it was any app - then Synapse is the app. And I can't installed something on bare domain - mydomain.com, if it's not served by Cloudron.
@girish it took me a while, but I can double-confirm you that Synapse could be installed and works fine, including federation on sub-domains.
The only problem now is that cloudron cut subdomain and only leaves domain in the config in various parts.
I had to enter synapse in recovery mode, change config, dump database, change domain to subdomain everywhere and then rewrite the database.
I would appreciate if you adjust the code on your side to just leave subdomain as is, without cutting it to domain.
And I didn't find a word in Synapse docs saying that you can't use subdomains. You shouldn't, but you definitively can.
As a side note: Cloudron's SSO completely ignores whitelabeling settings.
I found out that my matrix instances has been already migrated to SSO, so I had to look for a more straight-forward approach and it seems to be the following:
pip install matrix-commander
matrix-commander --login sso
cat credentials.json
Will give token without a need to use a client, especially in a cases where client is not a preferred options - like for bots.
@nebulon said in Another LDAP/OIDC sync issue - admin can't login:
What is the 401 response message body/text?
Seems to be empty:
As a guess: do you handle 2FA auth from slave/client LDAP Cloudron? I would guess it's a corner case and it's not handled.
Superadmin has 2FA enabled. Guess it could be also a problem.
@necrevistonnezr said in LDAP failing:
(I ️ block user on NodeBB)
Not sure why I need to know that... but: amen!
are you using the free tier
Negative.
as suggested by your previous topic
I have quite a few instances that I manage, including personal one.
And from what I recall, LDAP is not provided in free offer of Cloudron.
I still don’t see it
Yeah, I noticed.
Even if I would use Cloudron for free, it doesn't mean that bugs should not get fixed. And it definitely doesn't mean, that user has to fix it. Not in my world at least.