Web enthusiast.
I love Cloudron. I love the increasing number of apps offered. But will there eventually be too many for the Cloudron team to manage? I'd hate to see Support quality, or quality in general, decrease just for quantity. If there is to be a limit, how will it be determined? By install number? By usage? By active maintenance by the git repository/project owners (not Cloudron)?
I have a VPS with 24Gb of RAM. I have 19 apps. When I look at the Graphs the RAM usage is no more than 5 GB. But when I went to add the 20th app (Monica) I received this popup warning:
This Cloudron is running low on resources. Please upgrade to a server instance with more memory. Alternately, free up resources by uninstalling unused applications.
But my Graphs show that I have 20 GB of RAM unused. Is the warning about spikes or something?
Is it taking into account the RAM requirements for each installed app which would total 29.5GB? Is this why I get this warning?
@thetomester13 Oh man, if this goes live on Cloudron it'll make the start of the year AMAZING! Thank you all for working on it!
@vjvanjungg Hi. No, I haven't run into this. There has been only one other instance of a problem, but I can't recall what it was, but I believe it was related to Ghost versions upgrading. FWIW, the new native Ghost install and update method was super easy and convenient when I was running it on a separate VPS, but Cloudron is just so amazing in so many ways I decided to export my Ghost blogs and import them to my Cloudron VPS and host them here.
I love Cloudron. I love the increasing number of apps offered. But will there eventually be too many for the Cloudron team to manage? I'd hate to see Support quality, or quality in general, decrease just for quantity. If there is to be a limit, how will it be determined? By install number? By usage? By active maintenance by the git repository/project owners (not Cloudron)?
FWIW, https://cloudron.io/get.html does make it clear what the provider is:
Install Cloudron on your server
Create a fresh Ubuntu Bionic 18.04 x64 server and run these commands
wget https://cloudron.io/cloudron-setup
chmod +x ./cloudron-setup
./cloudron-setup --provider [digitalocean,ec2,generic,ovh,...]
A domain is required to install Cloudron.
I guess you could change the --provider option to --vps_provider to make it more clear. But it's pretty clear, especially for anyone who has already provisioned themselves a VPS, I would think. I'm just thinking that changing it will most likely end up with someone else not liking it, and then you change it, and then someone else.... TBH, do you really want to start replicating all the Digital Ocean tutorials here? That said, you all show incredible patience and a helpful attitude with all the questions that come your way. Good job!
@luckow I guess you are talking about the Enterprise Cloudron? I'm still trying to understand the situation you describe. My understanding is that Cloudron allows the paying customer (admin) to manage users, thus, the admin can create users (which are email based?) who can then access apps which the admin has created. When I look at https://cloudron.io/console.html#/userprofile?view=subscriptions I don't see any options for more than one admin, which is what it sounds like the op is asking for, unless that is what the Enterprise version is for. Even in the context you describe, it doesn't make sense to allow everyone/anyone admin access to your Cloudron account to then start installing and running any number of cloudrons. *which made me pause, because from what I understand any one cloudron can only be run under one domain. Why would you allow X number of users to access your my.domain.com cloudron to start installing whatever? How would you even monitor it to ensure no one is using more resources than they should? And if the answer is that they would not have access to admin1's cloudron but their own, then shouldn't they just make their own account? Or is it the idea that open source communities are exempt from paying (an option many other services make available)?
In terms of consistent user management, that is exactly what Cloudon already offers. The one admin user can create X number of users, such as admin@domain.com, user1@domain.com, user2@domain.com, and then even group them. Then, when creating an app, the admin user can then allow users, or users based on groups, access to the admin-created app, without the need for each user to have to manually create their own login for each app (for the most part, some of the apps aren't managed by the cloudron LDAP but manages users within itself).
But I suppose user1@domain.com might not like the admin-created username and prefers userA@domain.com, and thus allowing them to register themselves as such is preferable to trying to communicate to the admin. And then this cloudron-created user can use the LDAP advantage for signing into other apps too, using their preferred userA@domain.com. If THIS is what the OP is talking about, then I understand the nature of the request: Allowing a user to register themselves as a user within the cloudron LDAP without giving them any admin access.
Thank for reading all that. I'm trying to understand better.
@jdaviescoates Why do you want to do this? The apps available can by-and-large already allow a user to register for them. Letting others register under your Cloudron sounds similar to sharing your password with friends and family to share your Netflix. Why would others need to access your cloudron? Genuine question. (I guess my concern is increasing the load by more users without them paying for it, thereby possibly decreasing overall performance for those of us who do pay.)
@thetomester13 Oh man, if this goes live on Cloudron it'll make the start of the year AMAZING! Thank you all for working on it!
I have a VPS with 24Gb of RAM. I have 19 apps. When I look at the Graphs the RAM usage is no more than 5 GB. But when I went to add the 20th app (Monica) I received this popup warning:
This Cloudron is running low on resources. Please upgrade to a server instance with more memory. Alternately, free up resources by uninstalling unused applications.
But my Graphs show that I have 20 GB of RAM unused. Is the warning about spikes or something?
Is it taking into account the RAM requirements for each installed app which would total 29.5GB? Is this why I get this warning?
So I enabled Email for the new Dashboard domain (and left the old domain as-is), and went to login to SOGo using the new domain user credentials and voila, I could login fine. BUT it only shows the email for that specific new user. For some reason I was expecting SOGo to display the email accounts for all the users on my Cloudron - in this case I thought it would show the emails for both new and old domain names. I realize, after thinking about it, that in the case of a Cloudron being used by different users that you wouldn't want everyone's email viewable by everyone. But is it possible to have that option for a case like mine, where I have multiple domains with Email enabled, and so I could check some option in SOGo to display whichever addresses, rather than having to login to several different SOGo accounts? I went through the preferences of SOGo and thought that the IMAP ACCOUNTS section under Mail would let me add other email accounts, but it only lets me edit the current account.
So I changed the domain, and it worked fine. But I thought that the main user would also thus change. However, it seems that the cloudron is still using the previous domain as its main user. I tried uninstalling, then reinstalling SOGO in order to get the new user@newdomain.com credentials, but it it still only lets me login for the user@formerdomain.com credentials, as well as shows only the mail for user@formerdomain.com. Not the user@newdomain.com mail.
What do I do??
Thank you.
EDIT: I just noticed that Email is not enabled for the new Dashboard domain, and in fact, the only domain that has Email enabled is the old domain. So I guess I need to enable Email for the new Dashboard domain in order to have it accessible. BUT, the same question remains... will it then become the new default email/login??