Add Cgroup Limit Option to Plans

Submitted by volk on Mon, 04/24/2017 - 06:01 Pro Licensee

I know the CloudLinux topic has come up before and I think that personally, some people here are correct in their opinions that shared as it currently is not a viable option for most service companies (PHP abuse, Apache symlinks attacks, race escalation privileges, etc).

Now, it seems a type of Jail is already being worked on and when I suggested namespaces on the forums I was told nobody is using it (but that is not a reason not to innovate) and I also mentioned cgroups.

I may say that cgroups, that CloudLinux uses is already being implemented by some of your competitors. Plesk Onyx now seems to have cgroups build in and I don't see why Virtualmin could not benefit from it either as its built right into the operating system.

Here: https://docs.plesk.com/en-US/onyx/administrator-guide/plesk-administrati...

As you can see it has cgroups already and unless Virtualmin wants to be outpaced and fast I would SERIOUSLY, and I mean like if you really want to compete and stay relevant on offering an option to use resource limits with Virtualmin plans. It's a must requirement for shared providers. And that would be the right step in the future as well once it can play nice with a jail kit type of systems. Is is perfect? No, but is it stable? Yes, it's built into the OS for years now. Does it solve real problems? Absolutely! Is it hard to implement? No, not really. But it would be a pain to manage on multiple servers, so it should be done from VM. It would require a bit of change on the limits of the plans and if you want to build a resource manager where users can actually see their stats or consumption from their own panel, well that would be AWESOME and would put Virtualmin on a whole new level when it comes to hosting control panels.

I know you have Cloudmin but I didn't suggest this there because this is a feature in particular useful for shared type Apache virtual plans that run PHP and scripts. It has nothing to do with virtualization but just having a bit more control on accounts computing abuse on a server that has many websites hosted.

If someone wants my help on this, I'm happy to chip in, as I'm actually working on the feature regardless if you plan to add this or not. I'm just suggesting this here because common sense was that nobody else was doing it and that link proves some developers here wrong. Plesk did. At least Plesk Onyx is a nice surprise if you ask me since Plesk was sold they are doing quite interesting and nice things with their software. I would still not use them based on my previous year's bad experiences but they seem to be innovating a lot lately, including Docker support (which I also suggest here, to be able to launch a Docker app from Virtualmin but that actually runs on Cloudmin). This means, users can manage Docker from Virtualmin, but they, in reality, are managed from Cloudmin, Virtualmin is just a gateway to it for a specific app like Ruby, NodeJS, etc. that requires its own environment and can run on a standard shared account.

I know this may require some work but I really want to move the project forwards that direction. You have to start thinking above just deploying a regular Apache vhosts. It does not work in a multi-tenant environment anymore today unless there are a more strict resource and security control on accounts. This is something that users WOULD absolutely pay so it would be a nice welcome addition to the PRO edition. Why not? Vs paying Cloudlinux and just buying the PRO that has similar features, it's a no-brainer if you ask me. If this is done correctly it could boost Virtualmin sales.

Status: 
Active

Comments

Submitted by andreychek on Mon, 04/24/2017 - 08:55

Thanks for your input! We'll take a look at that.

Submitted by JamieCameron on Mon, 04/24/2017 - 18:33

Can cgroups also be used to chroot users? The jail support we're working on is only for chrooting (so far). My understanding is that cgroups are more useful for limiting resource usage, which is certainly something we could implement.

Submitted by volk on Tue, 04/25/2017 - 15:30 Pro Licensee

cgroups should not interfere with chroot, actually, it works fine with chroot, that is more or less what containers do, cgroups + chroot + namespaces.

Now, of course, we don't want to replicate containers here in anyway. That is not the purpose, cgroups does not provide any security features on its own, that is not the intention. Chroot should do that.

cgroups would just be a way to limit abusing accounts or hard limit them. Now, you could even consider that a security feature in some way. Why? One of the first indication of a compromised account on a shared server tends to be usually high resources and underperforming server, for example, high CPU, or a lot of PHP process or a server swapping memory.

The reason is that abused or compromised web accounts tend to maximize all the computing resources they can, by spamming, attacking other servers, etc. Cgroups is a good fit here because it avoids one account crashing services or monopolizing the rest of the server resource and affecting other accounts. That increases stability. Same for poorly configured scripts. So in a sense cgroups also provides some sort of security.

But this should not interfere with chroot. Chroot should still be implemented. While cgroups seems to be a way to isolate resources that is not really correct and not what cgroups is for. Cgroups purposes in this case would only be for two things. Limit abusing account, allow Virtualmin administrators to hard limit an account max resources.

This is different than virtualization like VM's, it's just a hard limit because accounts that go over limits not only tend to slow down and have performance issues, so its not really a way to sell computing slices, it is rather more a way to limit accounts from going over a specific plan limit, think of it like disk quotas on Linux but for CPU, IO and memory. Just like you set up a max bandwidth limit, and disk space limit, or users limit, you could configure on the plan a max CPU, or memory limit for the whole account (this is different than PHP limits on Virtualmin) as its for the entire account or at least per users.

I leave this for future reference: https://blog.engineyard.com/2015/linux-containers-isolation

Since cgroups is native and build into most Linux distros, it would be a good idea. I know the market is moving that way, hence people install CloudLinux and why Plesk also implemented this. I suspect Plesk implementation is basic and while this is nowhere near what CloudLinux does, it's a start, to say the least. With that in place, more interesting things can be done in the future.

Chroot is still a requirement; we don't want users accessing SSH to be able to see anything else besides their own filesystem.

Submitted by JamieCameron on Wed, 04/26/2017 - 00:14

This would be a really nice feature - I will add it to our project ideas list for future investigation.

Diabolico's picture
Submitted by Diabolico on Thu, 04/27/2017 - 18:43

And thinking when i mentioned CL and Virtualmin with all the benefits Jamie or Joe (or whoever it was) come to me with cynicism and "no one asked". Now they are developing their version of CL. Good and i'm happy for Virtualmin to finally get this features, still you are years late to the game.

Submitted by volk on Thu, 04/27/2017 - 19:02 Pro Licensee

The problem with CloudLinux:

  1. It's a commercial package (while they use free things like cgroups and other open sources stuff), it would still require extra payment per server.

  2. It is not supported officially on Virtualmin. It would require manual installation and babysit on upgrades. Not affordable to replicate on production servers. I have done it before, and it is messy to maintain.

  3. It requires a custom kernel and patching Apache and other things with their custom modules. Again we prefer to stick to something native to the OS or open source like cgroups. This would go apart with how Webmin/Virtualmin works and is designed, that means not touching or modifying the end software, we don't want to turn into a cPanel that installs its custom RPM's and modifies everything...Messy and horrible for native compatibility.

  4. Cgroups here is only a resource controller, in no way it isolates process for security like CloudLinux does, you would require namespaces and allot of other modifications to achieve that. So this is not a security feature but rather a selling feature so users can sell plans with specific computing limits (RAM, CPU, etc.).

cgroups is not hard to implement, native to most Linux distros and it does provide significant benefits. Its also very mature and was released over 10 years ago and is widely used now.

Submitted by cruiskeen on Fri, 05/05/2017 - 10:13

One should be aware that cgroups is deprecated in RedHat and CentOS 7 and most of this stuff is now integrated in systemd - cgroups can only be used for things not yet integrated in systemd. Cgroups is going to be removed some time in the future in CentOS and RedHat linux. I guess the way I REALLY should put this is that cgconfig and libcgroup are deprecated -- so you're really talking about having to do a different implementation to control this in 6 and 7 --

Submitted by volk on Fri, 05/05/2017 - 11:36 Pro Licensee

That would be the libcgroup tools, yes, but I'm not talking here about the tools. Just use whatever you see fit as management tools. It's the functionality we want. No problems using systemd instead or (put what you like here).