Is it possible to have something like cagefs so I can completely isolate each hosting account and control bandwidth, nodes etc .
I have not used cgroups implementation on virtualmin yet, but I believe it might need some TLC.
You can enable jails for a user, which is the same idea as cagefs (which is a cPanel thing, also seemingly based on chroot). Our implementation uses Jailkit, an Open Source tool for user jails.
You cannot control bandwidth with chroot. I donāt know what ānodesā youāre referring to.
There is no cgroups implementation in Virtualmin.
I thought there was basic restrictions done by pro and this was done by cgroups.
Inodes = number of files and account can have.
I am not an expert but full account restrictions offered as pro feature would be cool to stop one account/site killing the server which is one of the main things I want.
Hmm i thought this was already the case if you use a stock virtualmin setup, maybe Iām wrong and you appear to be an advanced linux server admin so I guess you know better
I am pretty sure that is not possible even without jails (I might be wrong) but without granting a user root access it is restricted to the domain owner then the acl access to each user and group. more an understanding of linux than windows
I āthinkā the idea here is that ALL resources are limited to something like a number or percentage of total resources available?
It is not done by cgroups. Itās done with /etc/security/limits.conf.
It could be more flexible and intuitive if it were done with cgroups, but itās not, currently. As it is, limits in Virtualmin Pro are pretty confusing for folks who donāt understand how limits.conf works.
Am I right that jails just control what commands and files a user can access, but does not control CPU, disk access I/o and things like that?
Of course. It puts the user in a chroot using Jailkit tools. That has nothing to do with CPU and resource usage.
I added a feature request:
I replied:
Itās super simple to manage on systemd systems by using slices to limit all processes a Unix user starts. You just need to add a drop-in to the systemd config directory and reload the daemon.
To be clear, the whole setup is as easy as creating a slice for a UID.
# /etc/systemd/system/user-1000.slice.d/10-limits.conf
[Slice]
CPUQuota=20%
MemoryMax=500M
ā¦and, running systemctl daemon-reloadāthis is something we could easily implement.
Sounds good, and just to be a newbie, some simple instructions to setup a ācagedā environment.
1 Like
Yes, itās as simple as toggling the āEnable Jailkit for domainā option under the āEnvironment limitationsā accordion on the āManage Virtual Server ā¾ Edit Owner Limitsā page.
So, @Jamie, I can implement it over a few evenings, I think.
Weāll place it under tabs in edit_res.cgi, with the existing functionality under the āLogin onlyā tab and the new systemd (if itās a systemd system) under the āAll processesā tab.
So, we can support both old and new configs with less effort for both the UI and CLI.
On the new tab, weāll have basic configs like limiting CPU%, CPU weight, memory high and max, tasks max, and disk read and write IO limits.
3 Likes
just a random thought, would adding the option of selecting ācagedā user accounts be something that should be added to the setup wizard?
Sure, that sounds pretty cool! Send me some PRs ..
1 Like
Alright, will do!
We should probably plan to drop the old limits.conf based resource limits as theyāre just too confusing for users. The way the limits are applied are kind of useless, as well (they make more sense for limiting specific processes, not for limiting users).
I guess the non-disruptive thing is to hide those options if they arenāt already in use.
What if we not only hide it but simply cleared what we previously set to limits.conf when the new form is saved? As it will be easier for us since we wonāt need to create tabs in the UI and make everything more complex.
Not pestering, but is this on the TODO list in the short term or is this a long term TODO project, I could not work out from the discussion above. 