Toward a "Domain of One's Own"
-
Hi all,
I have signed up for a managed plan to test some features of Cloudron. I really love the promise of a platform that is fundamentally based on managed containers.
The Question/Premise: Assume I want to support students enrolled in a class or academic program. I want each student to be able to have a blog, and perhaps one or more Wekan boards, and so on. From my experimentation, it looks like a single Cloudron instance cannot meet this need?
I created an administrator account and a student account. When I chose WP as one of my apps, both the administrator and the student are writing to the same blog. As a result, each "user" does not have their own blog space on a single (in this case, managed) Cloudron instance. However, each user does have their own Wekan board. Perhaps I'll have my students maintain microblogs in Wekan...
It seems to me that, given the current structure of Cloudron, that to provide every student with their own spaces, I would need:
- To have a VM for each student, and
- Provision Cloudron to that VM
We would create common admin accounts on each student VM, and they could then choose which apps to run on each virtual machine. Or, each student could be an admin of their own Cloudron instance. Details, details...
I guess the point of the question is: if I want to get into the space that every one of my students has a "domain of one's own," eg.
then is it likely that I must run a separate Cloudron instance for every student, or is there a way to simply run one server, with a bunch of RAM, and have each student running their own apps in their own containers?
(All of this might be my own confusion in some way, but I really do think I'm logged into two different browser instances, as two different Cloudron users, and still seeing the same WP instance in both cases. Hence my question.)
Many thanks,
Matt -
Hi,
if users get their own isolated or possibly shared resources like a board in wekan, depends highly on the app itself and what use-cases it provides. For wordpress, each app instance acts as its own website/blog on which the users, which have access to it can collaborate together. This means that if you want to provide isolated blogs for users, then each user would require its own wordpress app instance installed on the Cloudron on its own subdomain. The own subdomain sounds anyways like the use-case you have in mind here.
This leaves you with the two options, you already laid out there. Either each user gets his own Cloudron installed on a user specific domain, which would allow the user to install any app, entirely isolated from one another, or each user gets a wordpress app instance on a unified Cloudron instance and the access controls are set accordingly.
Those options would also imply that the unified Cloudron would have to be a larger server, with more resources, while one Cloudron per user, would likely work on small server instances. Considering server resource angle, this depends probably on how you can provision your infrastructure, basically if it works better for you to have one (or a few) large servers or a lot of small ones.
Hope this sheds some more light on this topic.
Johannes
-
Take a step back, guys!
Go for Firefox and install:-
Firefox Multi-Account Containers
https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/Then try logging on to a single Wordpress instance --- with different users in separate container tabs.
If that doesn't work, let me know.
Hope this helps!
-
@jadudm Thanks for your question.
As you have found, there are two possible setups. Single Cloudron shared across all the students or one cloudron per student.
Single Cloudron for all students
-
We assign a student "admin". All other students ask the student admin to install apps for them.
-
Each student is a user in Cloudron
-
When the student admin installs an app (say wordpress blog) for a student, the admin can use Cloudron's user management to restrict the access to the blog to just that student. https://cloudron.io/documentation/apps/#restricting-app-access-to-specific-users. This way the blog of various students don't mix. In addition, when students logs into the Cloudron dashboard, they only see apps that they have access to.
Pros:
- Can install apps that are shared across a group of students. Say a project needs a wekan board across 4 students. The student admin can simply install wekan and give access to those 4 students.
Cons:
- Creates friction to install apps since students have to go via an admin. This might just be my imagination from my life in the corporate world where each new layer exists just to say 'no'
Single Cloudron per student
-
The student is the admin of the Cloudron. They are assigned their domain like student.dept.institution.edu
-
Student can install blog, board, file sharing etc into subdomains of their assigned domain. No need to ask anyone.
Pros:
-
Each student feels empowered of their 'domain' which I think is important because it gives a feeling of ownership and responsibility (could be my imagination again!)
-
Student can easily migrate the Cloudron in it's entirety after graduation to their own server from the backups.
Cons:
- Creating apps that are shared across students can be tricky. Cloudron does not have a "federated" login yet. A possible workaround is to have a separate Cloudron allocated to such shared setups.
-
-
-
@girish said in Toward a "Domain of One's Own":
In addition, when students logs into the Cloudron dashboard, they only see apps that they have access to.
Am I wrong that this is not how it currently works? When logged in as a regular user the Cloudron dashboard shows all installs on the server.
I want to think the hurdle of an admin needing to do the installing is something external tooling utilizing the API could accomplish. As long as the permissions thing is worked out properly. Scaling a Cloudron server for each student sounds pretty expensive to me so I'm definitely more interested in the first scenario if the friction can be removed.
