I think the way you think to implement it is far superior that what I
thought of. My knowledge of the kernel isn't good enough to do it with
/proc so maybe I'll wait until you get around to it.
I don't think you need to seperate staff.
On my machine for example staff is uid's <1000 so what should be done is
to echo "1000" > /proc/blah and maybe echo "64" > /proc/blah_proccessesallowed
You can always hard & soft limit proccesses for staff later on with regular
limits. SO there are ways with crontab etc.. to get around them but I don't
expect most of my staff to try and bomb the system. If they will they won't
be staff anymore.
Andi
At 14:00 26/12/96 +1000, bofh@snoopy.virtual.net.au wrote:
>>put a cronjob to run a bomb and this won't have any effect.
>>ie. linux limits (and prolly most unicees) are useless.
>>I'm prolly going to hack the kernel a bit to do the following:
>>certain limit for uid's < 1000
>>and certain limit for uid's > 1000 (users)
>
> I've been thinking of doing a similar hack. However what I would do is put
>some files under /proc/sys to specify the UID number that differentiates
system
>processes from user processes (it's UID 100 on my systems but other people
will
>have different numbers) and to specify the number of processes for users (it
>would be a PITA if you hard-coded this into the kernel and then installed a
>program which couldn't run properly without the number being increased).
> Another thing I've been thinking about is the possibility of adding more
>classes of users. EG Staff could be allowed to run more processes than
average
>users, but we still need some limits (can't give them no limits as we do with
>system UIDs).
>
> What do you think?
>
>
>Russell Coker
>
>