I run RH9 on my linode, and I'm wondering how to put quotas on my user accounts, for disk usage, background processes, and CPU usage.

So far, I have found /etc/security/limits.conf, and the RH quota manager (quota, edquota, etc).

The problem with /etc/security/limits.conf is that it interferres with normal use. For example, I set the nproc (user processes) limit to 10 for users, then, testing this as a normal user, I found that many programs (like eggdrop, etc) simply failed to compile at all, because the ./configure program appeared to fork enough times that it hit the ulimit, failed its checks, and aborted.
I set the process limit to 20 in the end, but ideally I'd like to let users have 20 processes (so that they can configure, compile, etc) but only 3-5 background processes. However, there is no option that I can find to limit background processes without hindering compiling.

How do I limit the ammount of background processes users are allowed to run without affecting their foreground processes and without using /etc/security/limits.conf to set process limits that stop them being able to compile?

The problem with disk 'quota' is that I only have one partition on my linode, and therefore when I run quota, it can't unmount the partition and remount it read-only so that it can quotacheck.
I have considered reparitioning but I do not wish to do this as I worry that it might erase the considerable ammount of setup I have done so far. There is a resizer in disk configurations in members, and I have considered using this to shrink my partition, install another (small) redhat distro, reboot into that, then run quotacheck on my first partition while I am booted from my second. The problem with this approach is that I have to do this manually each time I want to check user quotas, and it causes a large ammount (hundreds of megs) of disk space to become 'reserved' for the second partition, which is harsh as I have little disk space spare anyway.
I was thinking of putting quotacheck commands into my boot sequence, but will this work? how could it be done, and, will it only check quotas on boot, thereby forcing me to reboot all the time?

How can I run quotacheck to setup user quotas for automatic enforcement, without reparitioning, or using the 'force' arguement to quotacheck? This arguement assumes no processes are changing the data on the drive, when they are, and therefore gives me inaccurate and skewed quota data?

quotacheck only needs to run occasionally. All it does it makes sure that the usage statistics it tracks in real-time are consistent with what is actually on the disk. I don't know if you can run it on a single partition; I would guess it would have to store data under /var somewhere.

But what I really wanted to advise is not to use a single partition, especially in a production system with users. I can appreciate that it is a pain to repartition a running system, but it will only be more painful later, for example, when you want to upgrade your kernel.

Erasing your setup shouldn't be a big worry. Here's what I would do in your situation:

1. If you don't have enough disk space to create a new system disk and user disk, temporarily buy more. It would only be for one month.

2. Create a new RH system disk, a new user disk, and another small system disk (Debian would be best). Edit the new RH configuration to access the user disk, and edit the small system disk configuration to access the old system disk, the new system disk, and the user disk.

3. Boot the small system disk. Create mount points and mount all the other disks (just to be safe, mount the old system disk read-only). Using tar, replace everything on the new system disk except /proc, /dev, and /home with the contents of the old system disk. Put the contents of the old /home onto the new user disk. Edit /etc/fstab on the new system disk to mount the new user disk at /home.

Now you should have two working configurations with identical systems. Boot into the new one - if something has gone terribly wrong, boot into the old one and mount the new user disk on /home (so any user activity goes to the new disk). When everything works, remove the old system disk and small system disk sometime before the month runs out. You'll get your users on a separate disk, you'll keep your current setup, and you'll never be without a working configuration.

Under that suggestion, would I only be able to enfoce quotas on the /home tree, as the / partition would still be subject to the same remount problem as before? If so, I would only be able to enforce quotas on /home, it would be a simple case of users creating files outside /home, say, in /tmp or /var, etc, for them to get around my quotas.

I might try this anyway though, as some quota is better then no quota, and it'd be good to have a well functioning partitioning setup.

I'm still working on limits.conf.


suggestion for linode.com : why not have a disk druid like program that runs when you first install software on your linode which helps you setup a suitable partition first time?

I don't know what the issues are, if any, with quotacheck on a root partition. For all I know, it can be made to work - I don't know much about how quota operates. But if you want to move multiple directories to another partition without having separate mounts for each one, you can mount your non-system disk somewhere like /mnt/ubdc and then make /home, /var/tmp, etc., symbolic links to directories at /mnt/ubdc/home, /mnt/ubdc/tmp, etc.

The problem with quotacheck on / is that you can't unmount the disk and remount it read only because you need to be able to run the actual quotacheck program, which in itself reads from /. You can only run quotacheck on / if you are using a different root filesystem. To do that, you need to reboot.... which necessitates rebooting into a different configuration each time you want to quotacheck on /, and results in either frequent reboots or out of date quoats.

Am I right here? I'm not sure, but I think that you can never quotacheck the filesystem on which the quotacheck program itself resides because to do so would require being able to remount that filesystem read only, which would require booting from a different root filesystem.... and causing the 'need to reboot all thet ime' problem.

Log into your linode's console (not ssh) then stop every service that is running (loggers, apache, ssh, etc). It should be pretty safe to force a quotacheck then as nothing should be writing to the drive, even if something was, odds are it'd only be a few k and would be owned by root anyways. I'm not a linux quota expert, but this has always worked for me.



Boot your linode into single user mode and you should be able to remount your root partition as ro as long as nothing is writing to it. I can't remember the exact mount arguement, but they should be easy to find.

kenny

Regarding creating new partitions, I'm interested in learning about that. Could you list some more reasons why this is a good idea?

Also, I'm wondering how the following case is handled. Let's say I have two "system" partitions and one user disk space partition. where if there's a file owned by user joeblow on the user disk space, and we're running system disk 1. But now we switch to booting off system disk 2, which doesn't have joeblow. What happens to that file?

Thanks.

Linux/Unix stores the user ID (the user number from /etc/passwd), not the actual user-name in the attributes of each file.

So, a file on a filesystem mounted inside a running system that is owned by user 500 (let's say "caker"), will just say "500" in "ls" on a system which doesn't have a passwd entry for UID 500.

The same thing happens when you (as root) un-tar an archive; it restores the UID on each file in the archive and you might not have that user on your system...

-Chris

This seems like a bad thing. Let's say there was another user 500 named "pie-er". Couldn't I, as root, inadvertently give pie-er access to caker's files just because they randomly had the same uid?

You could, but like you say, that would be bad. So don't do that. This is one of the many reasons systems administrators must be careful in their capacity as systems administrators.