Cloudron Forum

At the bottom of the user edit dialog there is a section for this. If the user has 2fa enabled it would look like this:

ba92d23e-ddaa-4850-bc1b-8078da14c862-image.png

@luckow thanks for your input 🙂

@luckow said in Merging mulitple Cloudrons in to one big new one?:

why?

In part just so everything in one place and so I just have to manage, maintain, update etc one server instead of several servers.

But also because e.g.

I've got an instance of PeerTube on one of the smaller VPSs (it's bridport.tv so makes sense to have it on my.bridport.coop where I've got all the Bridport stuff), but I've realised that it really needs a lot more power than that server has.

I'd also like to give access to some of the apps of got on my.uniteddiversity.coop to all the people on my.bridport.coop - at present this would mean them creating another account and then not having the same credentials for both (although to be fair most of the apps currently on my.bridport.coop aren't LDAP enabled anyway, either because they don't have it - like Discourse - or because it doesn't really suit the use case - public instances of PeerTube, Mastodon, Pixelfed).

I think quite a few of the apps would likely benefit for the increased power the dedicated server would have.

The issues you've highlighted wouldn't be that big an issue for me because I think I'm currently the only person/ name who is on all of them so there aren't two Jane Does (but there would be if I started saying "sign-up over on my.uniteddiversity.coop so I can give you access to our shared x too".

The biggest issue would be getting the handful of people actively using some of the other Cloudrons over onto the One Big Cloudron, but currently the numbers of people I'm talking about would be manageable (but this gets harder as more people start joining the other secondary Cloudrons).

Practically all apps won't handle it properly if you add/remove LDAP dynamically. You have to basically go and tinker with the database to move over users from ldap to local and vice versa. It's currently this way just to keep our support overhead low.

Like the immediate question after we add this is: how can I migrate LDAP users of xxx as local 🙂 This is impossible for us to support.

huh for some reason in my last session I did not see the search field but there is one. (Maybe I was just blind 🤷)

094213ff-47fe-41f3-b452-a341a216719f-grafik.png

I take it back, please don't throw stones 😄

This was a regression in 7.0. When user profiles are locked, the password is not reset properly. This is fixed in next release. Workaround for now is to disable locking of user profile. Alternately, you need this change - https://git.cloudron.io/cloudron/box/-/commit/37f066f2b0e4aa50ec45b387dd1d79b539d1aaf5

@girish what about just a normal organization level rights separation?
I mean - it's really two different set of roles:

1st line support, dealing with mailboxes 2nd or 3rd, making sure the system and services are up and running.

I don't need hiding anything, I just want to ensure my users can manage they mailboxes and users for they own.

For now I have to temporary give admin permissions to the 1st line and that's kind of risky...

This is fixed in the next release.

If you are curious, we had an async loop to fetch user objects. The responses were simply appended to an array. The sorting was thus messed us because the network response arrive out of order.

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.

@mario no problem 🙂

Merci beaucoup!

@NCKNE Currently, there is no way to tie two separate Cloudron's together. So, you are right that this sort of ends up with two separate user bases.

Thanks for your nice words! We do see this multi-host is requested often, so maybe it's something we can look into the next release.

@nebulon No worries, just thought I'd let you know

i didn't know cloudron was like active directory. or had active directory builtin.

@moonmeister I think it's better to use the username for login into all apps except the email apps like roundcube/rainloop/sogo (because they require email to know which mailbox to open).

The email login was probably not a good idea to start with because the email can be changed unlike the username. These days when we bring in new apps, we don't bother much with email login.

@scooke said in Make Alltube publicly available?:

Hi @jdaviescoates How did you get this to work?

I didn't do anything. Just installed it and it worked. But yes, I just download things onto my local machine.

Hello bortsed,

Cloudron offer ad LDAP server to be used by Apps like NextCloud, this is very useful if you use multiple apps in the same cloudron, or you use the email server provided with in Cloudron because you will have one account for everything.

If you use external service Cloudron can be setup to replicate an existing LDAP server, we for example for managing our desktops or laptops we are using Jumpcloud.

Yeah, email ids don't go via LDAP. Email ids and aliases are restricted because in other email systems people can use _, - and + as subaddress. Cloudron only supports + right now but might extend it to - and _.

@nebulon IIRC, the _ restriction comes when we had 1-1 mapping between username and email. Maybe it's not relevant anymore. I am more open in allowing it in usernames than mailbox names.

@yusf it should be safe now, can you please try (but we still have to show that banner because we are rolling out in batches).

@avatar1024 Thanks, I have put a note in our doc for now. We will try to put a note in the UI as well for next release - https://cloudron.io/documentation/user-management/#administrator

Also, users appearing in the app itself relies on LDAP sync which the app may or may not support. (This is why, just for consistency, we simply tell people to make sure users login to the app first.)

@girish this all sounds great - looking forward to the next release! 🙂

It would also be really nice if there was a simple way to limit the visibility of apps by domain (perhaps using groups?).

I realise that at present it's possible to create groups and then limit access to specific apps to specific groups, and that could be used now to achieve this, but I'd like a quicker and easier way to say to Cloudron: "this group has access to all apps on this domain" (but none of the other domains) than having to do it app by app.

Make sense?