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.
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.
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 ..
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. 